Findings: task 3.8 payload-aliasing defect found while starting 3.9

While orienting for task 3.9 (CONSOLE-CMD-EVENT cutover, per Captain
Bob's ruling to verify via a real QMP/serial-socket console session),
booting with a second real identity drive attached alongside Zuse's
own exposed a real defect in the already-closed task 3.8 code:
g_kh_blk_attach_buf (repl.c) is one static buffer, and
sk_hermes_send_one() stores payload_addr as a caller-owned pointer,
not a copy. Two real USB-MSC attaches in one sk_repl_idle() pass send
before either drains, so both messages alias the same buffer -- only
one identity ever completed.

Task 3.8's own write-up claimed this "carries the same single-buffer-
reuse shape ATTACH-ACK-BUF itself already had... not a new hazard" --
that claim was wrong and is amended in FABRIC-3.6.md's findings log.
FORTH's own MSG-SEND had the identical pointer-aliasing shape but
never hit the window: MSG-TICK drained from the same sk_repl_idle()
pass that queues attaches. Kernel-Hermes drains at interpret
checkpoints, which don't fire during that pass at all -- the cutover
changed not just how delivery happens but when, opening a window
FORTH's own design never had.

Reported, not fixed here, per Captain Bob's Law: this is a defect in
closed task 3.8 code, found while scoping a different task. A real
fix changes SkHermesMessage's own shape to own its payload bytes
rather than reference a caller's pointer -- bigger than a repl.c
patch, touches every existing sender, needs its own three-ISA
acceptance.

Task 3.9's own send-side cutover (kernel_hermes.h, repl.c) is written
but deliberately left uncommitted -- it would inherit the identical
defect shape if shipped now. logs/20260922-111840/amd64/ is the
reproduction.

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

FABRIC-3.6.md

@@ -1117,9 +1117,18 @@ 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`
+- [~] **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.
 - [ ] **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.**
 
@@ -1210,6 +1219,42 @@ mid-dispatch, exercised live for the first time by this exact task) is not somet
 as a fluke. Reported, not chased further here — `logs/20260922-092154/` is kept as the sole
 evidence.
 
+**2026-09-22, found while starting task 3.9 — task 3.8's `g_kh_blk_attach_buf` is a real
+payload-aliasing defect, not a benign restatement of an existing hazard as that task's own
+write-up claimed.** Discovered orienting for 3.9: booted amd64 with a second real identity drive
+("bob") attached at boot alongside Zuse's own (`QEMU_EXTRA` at port 2,
+`logs/20260922-111840/amd64/`), which puts two real USB-MSC devices through
+`sk_repl_idle()`'s per-slot attach loop in one pass — two `KH-BLK-ATTACH-SEND` calls before
+either drains. The ledger confirms it: `held=4096` (two admissions, 2×2048) at the first drain's
+own evidence print, not `held=2048` as every single-device boot this session showed. Only one
+device's identity ever completed (`Zuse: genesis minted...`); `S" bob" USE` afterward returned
+`USE: bob not found` — bob's own WIREBIND pairing never happened.
+
+**Root cause (following the code, not re-deriving it live):** `g_kh_blk_attach_buf`
+(`repl.c`) is one static buffer, and `sk_hermes_send_one()` stores `payload_addr` as a caller-
+owned pointer, not a copy. Two sends before either drain means both messages point at the same
+address — whichever send wrote last. **Task 3.8's own write-up claim that this "carries the same
+single-buffer-reuse shape `ATTACH-ACK-BUF` itself already had... not a new hazard this
+introduces" is wrong, and is amended here rather than left standing.** FORTH's own `MSG-SEND`
+had the identical pointer-aliasing shape, but never hit the window: `MSG-TICK` pumped from
+`sk_repl_idle()` itself, draining between attaches in the same loop that queues them.
+**Kernel-Hermes drains at interpret checkpoints, which do not fire during that idle-loop pass at
+all** — the cutover didn't just change *how* delivery happens, it changed *when*, and that's what
+opened a window FORTH's own design never had. Likely mechanism for why the second message
+produced no visible failure either (inference, not confirmed): both messages probably drained
+using the same (second-write) payload text, and the one carrying the wrong `dev-addr` most likely
+hit `repl.c:246`'s `found_slot == 0 || !pending` early return — silent, no print, ahead of this
+task's own evidence line. Not chased to confirm, per the scope decision below.
+
+**Not fixed here.** This is a defect in already-committed, closed task 3.8 code, found while
+scoping a different task — Captain Bob's Law: report, don't fix in passing. A real fix changes
+`SkHermesMessage`'s own shape (task 2.1) to own its payload bytes rather than referencing a
+caller's pointer, which is bigger than a `repl.c`-local patch: it touches every existing sender
+(tasks 3.3/3.5/3.6/3.8) and needs its own three-ISA acceptance. `logs/20260922-111840/amd64/` is
+kept as the reproduction — a second identity drive attached at boot is what exposes this; the
+default single-drive boot this whole document's other acceptance runs used never will. Task 3.9
+is paused pending Captain Bob's decision on when this gets fixed.
+
 ---
 
 ## Out of scope, carried for visibility