diff --git a/docs/rdp-debug-handoff.md b/docs/rdp-debug-handoff.md
index 3bbecfc..2845a07 100644
--- a/docs/rdp-debug-handoff.md
+++ b/docs/rdp-debug-handoff.md
@@ -143,22 +143,44 @@ machine's logs turned out to be wrong once the other machine's logs were checked
    `grdctl status --show-credentials` now consistently shows `Unit status: active`,
    `RDP: Status: enabled`, `Username: sam`, `Password: happy2026`.
 
-## The unresolved problem
+## UPDATE: connection now succeeds, but screen is blank
 
-Despite all of the above being fixed and verified consistent, connecting through ArchNest
-(browser → backend → guacd → Fedora VM) still fails with:
+The "Server refused connection (wrong security type?)" failure described below has since
+been resolved (cause not fully pinned down before it started working — likely one of the
+cert/credential/security-mode fixes finally lined up). The ArchNest Guacamole viewer now
+shows **"Connected"** in the top-right status, with the session named `Fedora-WS` — but the
+viewport is **solid black**, no desktop content ever renders. Confirmed NOT a lock-screen
+issue (user confirmed gnome is unlocked). `journalctl --user -u gnome-remote-desktop -n 50`
+checked at the time showed the daemon has been running continuously since 10:34:45 with no
+crash (unlike earlier attempts where "RDP server started" was immediately followed by
+"RDP server stopped") — so this is a *different* failure mode than the original refusal:
+**negotiation and session start now succeed, but no frame data is ever captured/sent.**
+
+This is strong evidence for the EGL/Mesa/Zink theory below — the daemon accepts the
+connection and starts the RDP server but apparently cannot capture real screen content,
+producing a connected-but-blank session instead of crashing outright. Next diagnostic step
+(not yet completed): tail `journalctl --user -u gnome-remote-desktop -f` AND
+`journalctl --user -f | grep -i -E "pipewire|portal|screencast|monitor"` *live*, while the
+black-screen session is open and the user clicks/moves the mouse in the Guacamole viewport,
+to catch any PipeWire/portal screencast error that doesn't appear in the regular unit log.
+
+## Original unresolved problem (superseded by the above, kept for history)
+
+Connecting through ArchNest (browser → backend → guacd → Fedora VM) used to fail outright
+with:
 
 ```
 Error: Server refused connection (wrong security type?)
 ```
 
-This has been tried with `security` set to `any`, `nla`, `tls`, and `rdp` — **identical
+This was tried with `security` set to `any`, `nla`, `tls`, and `rdp` — **identical
 failure every time**, regardless of mode. That's suspicious: if it were a genuine security
 negotiation mismatch, different modes should fail differently (or some should succeed).
-The fact that they all fail identically suggests the real failure might be happening
+The fact that they all failed identically suggested the real failure might be happening
 *after* security negotiation succeeds — e.g. at session-start/framebuffer-creation time —
 and FreeRDP's client-side error message is a generic/misleading bucket for "the connection
-didn't complete," not literally a security-type mismatch.
+didn't complete," not literally a security-type mismatch. This symptom is no longer
+reproducing (see UPDATE above) — leave this section for historical context only.
 
 ### Open theory (unconfirmed)