FABRIC-3.md: close WIREBIND, the real attach call site (§F.23)

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019ZGkimpfyh63EZyRkNbkPD

FABRIC-3.md

@@ -2960,3 +2960,45 @@ async-over-synchronous decision, but a real UX question for later if it proves t
 practice; whether a console VM should get a default subscription to `COMMON-CH` (skipped in
 v1 — direct 1:1 console↔user traffic doesn't need it, and it would require resolving an index
 in Hermes's own routing table for a VM that doesn't have one yet).
+
+### F.23 — `WIREBIND`: the real attach call site, no manual steps
+
+Every phase closure from §F.18 through §F.22 pointed at the same gap: `RUNCAP-TEST` and
+`PAIR-TEST` were diagnostic scaffolding, exercising `CERTVERIFY`/`RUNCAP`/the console pair by
+hand, not a real attach flow. `WIREBIND` (§F.5, originally a breadcrumb) closes it — and
+turned out to be assembly, not new design: every hard decision it needed was already made in
+earlier scoping (§F.9's ACL-comparison rules, §F.7's cert trust model), and `CERTVERIFY`'s own
+orchestration already existed (`vm_identity_from_cert()`, Phase A/B — verify-signature +
+check-serial + extract-owner-pubkey in one call) — it had just never been wired to a live
+attach.
+
+**The flow** (`capsule_wirebind_try_attach()`, called from `sk_repl_idle()` alongside
+`capsule_zuse_boot_try_attach()`, same `HOMEBLOCKS_SIG_OK` hook): `sig->cert_offset == 0`
+means this is Zuse's own genesis-mode drive (no cert region, §F.21) — that's already the other
+function's job, skip. Otherwise, with Zuse already authenticated this boot (nothing to verify
+a regular cert against otherwise — a real precondition, not an oversight), read the cert
+devblock(s) and call `vm_identity_from_cert()` against `mama_vm`'s own `zuse_cert_pubkey` and
+the drive's `drive_uuid`. On success: read the drive's own `user_identity_seed_t` for its
+`username`, birth a console VM + `RUNCAP`-born user VM pair (idempotent — no-ops if that
+username is already live this session), install the verified `VMIdentity` onto the user VM,
+register the `"<username>~user"` pairing `sk_repl_dispatch_line()` (§F.22) looks for.
+Deliberately does **not** auto-`USE` the new console — that stays an explicit, `BINDSTEP`-gated
+step (§F.9), not something a bare attach should trigger silently.
+
+**Verified end-to-end, live, including a genuine negative case — not just the happy path:**
+attached `disk/user1.img` (its cert signed by a *different*, earlier-session Zuse instance —
+Zuse's own keypair is freshly random every genesis mint) and got `"WIREBIND: cert verification
+FAILED -- drive refused"` — real proof the check actually verifies against the *live* session's
+own root, not a rubber stamp. Minted a fresh identity with *this* boot's own Zuse
+(`S" Sam Sample" S" SamS" ... MINT`), reattached, and got `"WIREBIND: SamS attached and ready
+-- USE it to begin"` printed with **zero manual commands** — no `PAIR-TEST`, no `RUNCAP-TEST`.
+Followed by a clean `USE SamS` and a working async `WELCOME` relay end to end, identical in
+shape to §F.22's own manual-pairing proof. Clean 3-architecture regression: Hermes/Artemis
+both birth live, no unexpected ACL denials or `UNKNOWN WORD`. Commit `6fc0ee3`.
+
+**Still open:** `BINDSTEP` itself (§F.9) — `USE` is still unguarded; `WIREBIND` installs a real
+`VMIdentity` onto the user VM but nothing re-verifies it on `USE` yet, so the ACL-gated
+re-attach check that closes this whole identity arc is the one piece left. The fence-marker
+persistence gap (§F.21) still means Zuse can't re-authenticate across a real reboot in this
+QEMU environment — worked around for this verification the same way, via a fresh genesis mint
+within the same boot session, not fixed here.