Console prompt: identity/machine both sides once redirected off Hera

sk_console_user_prefix() (repl.c) previously always returned "zuse"
(or the WIREBIND-attached username) as the left side of the bracket
prefix, regardless of which VM the console was actually pointed at --
"[zuse@rajames]" after USE rajames, always showing the authenticating
superuser rather than the active identity.

Changed on Captain Bob's direct instruction: once the console is
redirected into a WIREBIND identity's own console VM
(console_get_vm_name() != "Hera"), show that same name on both sides
-- "[rajames@rajames]" -- since WIREBIND births the console VM
literally named after the identity, so the identity IS that VM, not a
separate label. At the top level (still on Hera, nothing has
redirected yet), the original zuse_session/WIREBIND-username logic is
unchanged.

An earlier, more ambitious attempt (separate identity/machine tracked
state across every console_set_vm_name() call site) regressed live to
a wrong [zuse@Artemis] prompt and was fully reverted before reaching
any acceptance run -- the landed fix needed none of that new state,
just this one function.

Verified live on all three architectures: [zuse@Hera] at the top
level and after a live WIREBIND attach (before USE), [rajames@rajames]
after USE rajames, with task 3.9's Stage D relay still firing
correctly on top of it. Zero UNKNOWN WORD, dict_hash unaffected
(display-only change).

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

FABRIC-3.6.md

@@ -1323,6 +1323,51 @@ kept as the reproduction — a second identity drive attached at boot is what ex
 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.
 
+**2026-09-22, out-of-band request during task 3.9's own verification — console prompt format
+changed on Captain Bob's direct instruction, not a reshuffle task, no task number.** The bracket
+line prefix (`console.c`'s `emit_prefix()`, unchanged) used to read
+`[<session-owner>@<active console/identity>]` — e.g. `[zuse@rajames]` after `USE rajames`, always
+showing the authenticating superuser on the left regardless of which identity the console was
+actually redirected to. Corrected across several rounds of live clarification to: once the
+console is redirected into a WIREBIND identity's own console VM (`console_get_vm_name() !=
+"Hera"`), show that same name on **both** sides — `[rajames@rajames]`, not `[zuse@rajames]` —
+because WIREBIND births the console VM literally named after the identity
+(`capsule_console_birth()`), so the identity *is* that VM, not a separate label layered on top of
+it ("R.A. James is also a VM," Captain Bob's own reasoning). At the top level (still on Hera,
+nothing has redirected the console yet — e.g. a live WIREBIND attach announced but not yet
+`USE`'d into), the original `zuse_session`/`capsule_wirebind_attached_username()` logic is
+unchanged, since Hera's own name doesn't say who's driving her.
+
+**First attempt regressed live and was reverted before being carried into any acceptance run.**
+An initial, more ambitious design (separate "identity" vs. "machine" tracked state, touching
+every `console_set_vm_name()` call site across `BIRTH`/`RUN`/`VM-EXEC`/`VM-CALL`/`CONNECT-*` in
+`mama_forth_words.c`) produced a wrong `[zuse@Artemis]` prompt live, because the machine segment
+only ever got updated on the way *in* to a temporary excursion (e.g. into Artemis's own context
+during a birth), never restored on the way back out for a "restore to a non-fleet-member name"
+case. Caught by `advisor()` before it reached any committed acceptance run; fully reverted
+(`console.c`, `console.h`, `repl.c`'s registration all restored byte-for-byte to their prior
+committed state) rather than patched forward. The landed fix, below, needed none of that new
+state.
+
+**Landed fix: `sk_console_user_prefix()` alone** (`repl.c`) — when `console_get_vm_name() !=
+"Hera"`, return it directly (emit_prefix() then prints it on both sides of the `@`, unchanged
+otherwise); else keep the original `zuse_session`/WIREBIND-username logic. Zero new state, zero
+other call sites touched. Verified live, interactively, on all three architectures (same
+mint → WIREBIND-attach → `USE` → typed console line shape as task 3.9's own acceptance):
+`[zuse@Hera]` at the top level and immediately after a live WIREBIND attach (before `USE`),
+`[rajames@rajames]` after `USE rajames`, Stage D relay (task 3.9) still fires correctly on top of
+it. Zero `UNKNOWN WORD`, `dict_hash` identical to every prior acceptance run in this document
+(unaffected — this is a display-only change). Logs:
+`logs/20260922-133732/amd64/`, `logs/20260922-134049/aarch64/`, `logs/20260922-134638/riscv64/`.
+
+**Separately raised, not yet actioned: background diagnostic console noise
+(`[Hestia@Hestia]`/`[Hermes@Hermes]` `INFERENCE: Output validation failed` warnings, `HADES`
+xhci error/warn lines) interleaves visibly with interactive console output**, confirmed live via
+a QMP `screendump` Captain Bob asked for mid-task. Matches this project's own already-tracked,
+not-yet-started item (memory `project_production_logging_cleanup_needed`:
+`console_println()` overuse, much of it should be DEBUG-level). Captain Bob explicitly deferred
+this to after the prompt-format fix landed — genuinely not started, no task number assigned yet.
+
 ---
 
 ## Out of scope, carried for visibility

src/starkernel/repl.c

@@ -81,12 +81,32 @@ static void sk_print_prompt(void) {
     console_puts(SK_PROMPT_TEXT);
 }
 
-/* console_user_prefix_fn provider (console.h) -- same zuse_session/
- * WIREBIND-username logic sk_print_prompt() used to compute inline
- * before this moved into the shared line prefix. Registered once at
- * boot (sk_repl_run()'s own init, see below); NULL until then, which
- * console.c's emit_prefix() already treats as "no provider yet." */
+/* console_user_prefix_fn provider (console.h). 2026-09-22, Captain
+ * Bob's own instruction, restated precisely across several corrections
+ * this session: once a WIREBIND identity's own console is active (the
+ * physical console has been `USE`'d into it), the bracket must show
+ * that SAME name on both sides -- "[rajames@rajames]", not
+ * "[zuse@rajames]" -- because the identity console_get_vm_name()
+ * already tracks (WIREBIND births the console VM literally named after
+ * the human, mama_forth_words.c's capsule_console_birth()) IS her own
+ * VM, not a separate "who's driving" label layered on top of it.
+ * "R.A. James is also a VM" was the exact reasoning given.
+ *
+ * Below the top level (console_get_vm_name() != "Hera", i.e. USE or a
+ * BIRTH/RUN/CONNECT-* redirect has pointed the console somewhere else),
+ * that target's own name already answers "who/what is this" -- return
+ * it directly, and emit_prefix() ends up printing it on both sides
+ * (this function's return @ console_get_vm_name(), unchanged). At the
+ * top level (still on Hera, nothing has redirected the console yet),
+ * her own name doesn't say WHO is driving her, so this keeps the
+ * original zuse_session/WIREBIND-username logic for that one case --
+ * unchanged from before this fix, still correct: a live WIREBIND
+ * attach announces itself before USE is ever typed
+ * ("WIREBIND: <name> attached and ready -- USE it to begin"), and the
+ * prompt should already reflect that. */
 static const char *sk_console_user_prefix(void) {
+    const char *vn = console_get_vm_name();
+    if (vn && strcmp(vn, "Hera") != 0) return vn;
     VM *mama_vm = (VM *)sk_get_mama_vm();
     if (mama_vm && mama_vm->zuse_session) return "zuse";
     return capsule_wirebind_attached_username();