docs(wiki): refresh status to 436cbf9d - DDX/X-stability walls closed, sections execute, push bodies decode above 10 GiB; remaining wall = direct-GL payload delivery (setup push recycled; draws 0x4250000)

12 files changed, 251 insertions, 180 deletions

diff --git a/wiki/.publish-manifest.json b/wiki/.publish-manifest.json
index 45c012c..24a5be5 100644
--- a/wiki/.publish-manifest.json
+++ b/wiki/.publish-manifest.json
@@ -64,11 +64,11 @@
  },
  "FAQ": {
   "file": "FAQ.wiki",
-  "new_revid": 24124,
-  "old_revid": 24109,
-  "source_sha": "64db259975af254e",
-  "summary": "2026-11-12 status refresh: X/GLX fully green, GPU-rendered captures, direct-GL command-stream delivery wall",
-  "timestamp": "2026-11-13T00:10:29Z",
+  "new_revid": 24138,
+  "old_revid": 24124,
+  "source_sha": "80d4a61ec210c032",
+  "summary": "2026-11-13 status refresh: X/DDX stability walls closed, GR forward lane live, push-body PA-bound fix; direct-GL payload VAS registration is the wall",
+  "timestamp": "2026-11-13T16:12:01Z",
   "title": "FAQ"
  },
  "GMMU Multi-Tenant Protection": {
@@ -127,11 +127,11 @@
  },
  "Graphics Execution": {
   "file": "Graphics-Execution.wiki",
-  "new_revid": 24125,
-  "old_revid": 24119,
-  "source_sha": "ca2568313ad7585d",
-  "summary": "2026-11-12 status refresh: X/GLX fully green, GPU-rendered captures, direct-GL command-stream delivery wall",
-  "timestamp": "2026-11-13T00:10:31Z",
+  "new_revid": 24134,
+  "old_revid": 24125,
+  "source_sha": "8da8637bb0987273",
+  "summary": "2026-11-13 status refresh: X/DDX stability walls closed, GR forward lane live, push-body PA-bound fix; direct-GL payload VAS registration is the wall",
+  "timestamp": "2026-11-13T16:11:55Z",
   "title": "Graphics Execution"
  },
  "Guest Driver Lifecycle: A Field Guide": {
@@ -226,11 +226,11 @@
  },
  "OpenGL": {
   "file": "OpenGL.wiki",
-  "new_revid": 24127,
-  "old_revid": 24120,
-  "source_sha": "c828d16906f241c5",
-  "summary": "2026-11-12 status refresh: X/GLX fully green, GPU-rendered captures, direct-GL command-stream delivery wall",
-  "timestamp": "2026-11-13T00:10:35Z",
+  "new_revid": 24135,
+  "old_revid": 24127,
+  "source_sha": "05daf3eaa0974cd9",
+  "summary": "2026-11-13 status refresh: X/DDX stability walls closed, GR forward lane live, push-body PA-bound fix; direct-GL payload VAS registration is the wall",
+  "timestamp": "2026-11-13T16:11:56Z",
   "title": "OpenGL"
  },
  "Performance": {
@@ -244,38 +244,38 @@
  },
  "Physical GPU Backend and Guest Wiring": {
   "file": "Physical-GPU-Backend.wiki",
-  "new_revid": 24128,
-  "old_revid": 24113,
-  "source_sha": "9ec1fb4ad252fb43",
-  "summary": "2026-11-12 status refresh: X/GLX fully green, GPU-rendered captures, direct-GL command-stream delivery wall",
-  "timestamp": "2026-11-13T00:10:36Z",
+  "new_revid": 24140,
+  "old_revid": 24128,
+  "source_sha": "e371b8347739f412",
+  "summary": "2026-11-13 status refresh: X/DDX stability walls closed, GR forward lane live, push-body PA-bound fix; direct-GL payload VAS registration is the wall",
+  "timestamp": "2026-11-13T16:12:04Z",
   "title": "Physical GPU Backend and Guest Wiring"
  },
  "Project Goals": {
   "file": "Project-Goals.wiki",
-  "new_revid": 24129,
-  "old_revid": 24121,
-  "source_sha": "172124308519a378",
-  "summary": "2026-11-12 status refresh: X/GLX fully green, GPU-rendered captures, direct-GL command-stream delivery wall",
-  "timestamp": "2026-11-13T00:10:37Z",
+  "new_revid": 24141,
+  "old_revid": 24129,
+  "source_sha": "e85b6ef4869f5837",
+  "summary": "2026-11-13 status refresh: X/DDX stability walls closed, GR forward lane live, push-body PA-bound fix; direct-GL payload VAS registration is the wall",
+  "timestamp": "2026-11-13T16:12:05Z",
   "title": "Project Goals"
  },
  "Project Plan": {
   "file": "Project-Plan.wiki",
-  "new_revid": 24130,
-  "old_revid": 24115,
-  "source_sha": "d1eb43a3ff142501",
-  "summary": "2026-11-12 status refresh: X/GLX fully green, GPU-rendered captures, direct-GL command-stream delivery wall",
-  "timestamp": "2026-11-13T00:10:37Z",
+  "new_revid": 24142,
+  "old_revid": 24130,
+  "source_sha": "649625a12da890ce",
+  "summary": "2026-11-13 status refresh: X/DDX stability walls closed, GR forward lane live, push-body PA-bound fix; direct-GL payload VAS registration is the wall",
+  "timestamp": "2026-11-13T16:12:07Z",
   "title": "Project Plan"
  },
  "Project Status": {
   "file": "Project-Status.wiki",
-  "new_revid": 24131,
-  "old_revid": 24116,
-  "source_sha": "836675c834215a40",
-  "summary": "2026-11-12 status refresh: X/GLX fully green, GPU-rendered captures, direct-GL command-stream delivery wall",
-  "timestamp": "2026-11-13T00:10:38Z",
+  "new_revid": 24133,
+  "old_revid": 24131,
+  "source_sha": "f60917535300a33e",
+  "summary": "2026-11-13 status refresh: X/DDX stability walls closed, GR forward lane live, push-body PA-bound fix; direct-GL payload VAS registration is the wall",
+  "timestamp": "2026-11-13T16:11:53Z",
   "title": "Project Status"
  },
  "RPC Message Format": {
@@ -289,11 +289,11 @@
  },
  "System Overview": {
   "file": "System-Overview.wiki",
-  "new_revid": 24132,
-  "old_revid": 24117,
-  "source_sha": "ca0eeca2caf2429f",
-  "summary": "2026-11-12 status refresh: X/GLX fully green, GPU-rendered captures, direct-GL command-stream delivery wall",
-  "timestamp": "2026-11-13T00:10:40Z",
+  "new_revid": 24143,
+  "old_revid": 24132,
+  "source_sha": "0e395cbae9a0b86f",
+  "summary": "2026-11-13 status refresh: X/DDX stability walls closed, GR forward lane live, push-body PA-bound fix; direct-GL payload VAS registration is the wall",
+  "timestamp": "2026-11-13T16:12:08Z",
   "title": "System Overview"
  },
  "Template:About message": {
@@ -325,11 +325,11 @@
  },
  "The Execution Frontier": {
   "file": "Execution-Frontier.wiki",
-  "new_revid": 24122,
-  "old_revid": 24107,
-  "source_sha": "330aaccbf09e44fb",
-  "summary": "2026-11-12 status refresh: X/GLX fully green, GPU-rendered captures, direct-GL command-stream delivery wall",
-  "timestamp": "2026-11-13T00:10:28Z",
+  "new_revid": 24136,
+  "old_revid": 24122,
+  "source_sha": "04c55fec2dda09b5",
+  "summary": "2026-11-13 status refresh: X/DDX stability walls closed, GR forward lane live, push-body PA-bound fix; direct-GL payload VAS registration is the wall",
+  "timestamp": "2026-11-13T16:11:58Z",
   "title": "The Execution Frontier"
  },
  "The Guest Stack and CUDASW": {
@@ -343,20 +343,20 @@
  },
  "The Host Module (vgsp.ko)": {
   "file": "Host-Module.wiki",
-  "new_revid": 24126,
-  "old_revid": 24111,
-  "source_sha": "9a0cd0079d648c1f",
-  "summary": "2026-11-12 status refresh: X/GLX fully green, GPU-rendered captures, direct-GL command-stream delivery wall",
-  "timestamp": "2026-11-13T00:10:33Z",
+  "new_revid": 24139,
+  "old_revid": 24126,
+  "source_sha": "6700460dbaa01a68",
+  "summary": "2026-11-13 status refresh: X/DDX stability walls closed, GR forward lane live, push-body PA-bound fix; direct-GL payload VAS registration is the wall",
+  "timestamp": "2026-11-13T16:12:02Z",
   "title": "The Host Module (vgsp.ko)"
  },
  "The vGSP Execution Plane (vEP)": {
   "file": "Execution-Plane.wiki",
-  "new_revid": 24123,
-  "old_revid": 24108,
-  "source_sha": "efae696755438733",
-  "summary": "2026-11-12 status refresh: X/GLX fully green, GPU-rendered captures, direct-GL command-stream delivery wall",
-  "timestamp": "2026-11-13T00:10:28Z",
+  "new_revid": 24137,
+  "old_revid": 24123,
+  "source_sha": "68edee8a9ca705d1",
+  "summary": "2026-11-13 status refresh: X/DDX stability walls closed, GR forward lane live, push-body PA-bound fix; direct-GL payload VAS registration is the wall",
+  "timestamp": "2026-11-13T16:11:59Z",
   "title": "The vGSP Execution Plane (vEP)"
  },
  "UVM in the Guest": {
diff --git a/wiki/Execution-Frontier.md b/wiki/Execution-Frontier.md
index f5bfa9d..5af5e6d 100644
--- a/wiki/Execution-Frontier.md
+++ b/wiki/Execution-Frontier.md
@@ -14,7 +14,7 @@
 > [`../docs/04-implementation/03-execution-frontier.md`](../docs/04-implementation/03-execution-frontier.md);
 > the docs tree wins on disagreement.
 
-Status: 2026-11-12, tree `master @ 800c108f`.
+Status: 2026-11-13, tree `master @ 436cbf9d`.
 Tags: `[live]` observed; `[wip]` partial; `[wall]` current blocker; theories
 are labelled as such.
 
@@ -104,10 +104,15 @@ replay executes; the **first non-black GPU-rendered output** landed: a
 pbuffer probe returns `pixel=ff0000ff`, the off-screen path produced 500/500
 non-black 640x480 frames per run and captured videos (45.4 s on 2026-11-11, a
 50 s capture on 2026-11-12), and GZDoom reaches `V_Init: allocate screen`
-with its GL 4.6.0 context when the shared nvClip `modeNum` is even. What is
-missing is **window/screen pixels through the NVIDIA path**: the direct-GL
-client's own 59,556-byte setup push is not yet resolvable/readable host-side
-under the client's page-directory churn, so its draw sections never reach the
+with its GL 4.6.0 context when the shared nvClip `modeNum` is even. The X
+side of the path was hardened in the 11-12/11-13 wave (DDX idle-DMA/ScreenInit,
+USERD-latch, re-probe, kernel-mode spin and flip-event walls closed; X green
+for more than 10 minutes), captured GL sections now execute on the engine, and the
+direct-GL push bodies decode as real GR method streams above 10 GiB through
+the VAS walk. What is missing is **window/screen pixels through the NVIDIA
+path**: the direct-GL payload VAs (`0x4001004` setup push,
+`0x4250000`/`0x4250110` draws) still resolve to zero/implausible PAs because
+their user/UVM VAS is never registered, so its draw sections never reach the
 engine, glxgears' window is black, and a synchronous window draw wedges X on
 some boots. The guest Vulkan pipeline's inline-to-memory upload arm is its
 gap. The full picture lives on
@@ -170,13 +175,17 @@ CUDA guests is in progress.
 **Issue D — the graphics pixel frontier.** The display/KMS stack and the GL
 client now run end to end (NvKms registers, X settles, the stock GLX path is
 fully green with glxinfo 4.6.0 and ~520 FPS glxgears, the DDX 3D replay
-executes, the first non-black GPU-rendered frames and videos are captured
-off-screen, and the direct-GL ring/USERD machinery is substantially hardened);
-but the direct-GL client's 59,556-byte setup push is not yet readable/
-resolvable host-side under its page-directory churn, so its draw sections
-never open on the engine, glxgears' window is black, and a window draw wedges
-X on some boots. Command-stream delivery, the window/screen present and X
-screen-init stability are the named blockers
+executes, the X DDX/ScreenInit stability walls are closed with X green >10
+minutes, captured GL sections execute on the engine, the first non-black
+GPU-rendered frames and videos are captured off-screen, and the direct-GL
+ring/USERD machinery is substantially hardened); client push bodies now
+decode as real GR method streams above 10 GiB via the VAS walk. The remaining
+gap is registration: the direct-GL payload VAs (`0x4001004` setup push,
+`0x4250000`/`0x4250110` draws) still resolve to zero/implausible PAs because
+their user/UVM VAS is never registered, so its draw sections never open on
+the engine, glxgears' window is black, and a window draw wedges X on some
+boots. Command-stream delivery, the window/screen present and the X
+first-generation screen-init lottery are the named blockers
 ([`Graphics-Execution.md`](Graphics-Execution.md)).
 
 ## 6. Lines of investigation (live)
@@ -191,11 +200,11 @@ screen-init stability are the named blockers
 4. **Hold the acceptance battery** — vector-add, matrix-multiply and the
    transformer kernel; each entry is accepted only on its own verification
    output (`bad=0` + `STATUS OK`).
-5. **The graphics pixel frontier** — make the direct-GL client's command
-   stream (the 59,556-byte setup push and its ring/CE siblings) resolve and
-   execute host-side, make the window/screen present land, and stabilise X
-   screen-init across boots so the proven off-screen frames become window
-   pixels; the lanes, the walls and the milestone ladder are on
+5. **The graphics pixel frontier** — register the direct-GL payload user/UVM
+   VAS (or pin the payload set from the guest pagemap) so the setup push and
+   draw pushes resolve, make the window/screen present land, and reduce the X
+   first-generation screen-init lottery so the proven off-screen frames
+   become window pixels; the lanes, the walls and the milestone ladder are on
    [`Graphics-Execution.md`](Graphics-Execution.md).
 
 ## 7. Theories, resolved
diff --git a/wiki/Execution-Plane.md b/wiki/Execution-Plane.md
index 88fbc9a..4fa4b51 100644
--- a/wiki/Execution-Plane.md
+++ b/wiki/Execution-Plane.md
@@ -8,7 +8,7 @@
 > when the two disagree, the docs tree wins. Front door:
 > [`../docs/README.md`](../docs/README.md).
 
-Status: 2026-11-12, tree `master @ 800c108f`. Tags: `[live]` proven with the
+Status: 2026-11-13, tree `master @ 436cbf9d`. Tags: `[live]` proven with the
 stock guest driver; `[gated]` implemented, default-off or parameter-gated;
 `[wip]` partial; `[wall]` current blocker; `[target]` named success latch;
 `[planned]` designed, not built.
@@ -148,17 +148,24 @@ guest: push + QMD + GPFIFO entry + doorbell (BAR0 0x88704)
   the emulated display engine (modeset push buffers plus the
   notifier/`UPDATE` completion, class-aware arm), so NvKms registers, X
   settles and the stock NVIDIA GLX path is fully green (`glxinfo -B` rc 0,
-  OpenGL 4.6.0 direct, `glxgears` ~520 FPS); the X DDX waits are fixed, and
-  the guest's real GL draws now forward and execute on the physical GPU
-  (`backend_ok=5-7`, `backend_timeout=0`); the DDX 3D replay executes, the 2D
-  path is green, the direct-GL ring/VAS and USERD machinery is hardened, and
-  the first non-black GPU-rendered frames are proven (500/500 off-screen
-  frames per run plus captured 45.4 s and 50 s videos). No non-black
+  OpenGL 4.6.0 direct, `glxgears` ~520 FPS); the X DDX waits are fixed (the
+  idle-DMA/ScreenInit, USERD-latch, re-probe, kernel-mode-spin and flip-event
+  walls are closed, and X has stayed green >10 minutes), and the guest's real
+  GL draws now forward and execute on the physical GPU (`backend_ok=5-7`,
+  `backend_timeout=0`); captured GL sections execute on the engine
+  (`GR LAUNCH submitted` / `GUEST GR LAUNCH OK`) with the data window
+  populated, the DDX 3D replay executes, the 2D path is green, the
+  direct-GL ring/VAS and USERD machinery is hardened, and the first non-black
+  GPU-rendered frames are proven (500/500 off-screen frames per run plus
+  captured 45.4 s and 50 s videos). Client push bodies decode as real GR
+  method streams above 10 GiB through the VAS walk (`436cbf9d`). No non-black
   **window/screen** frame has been produced through the NVIDIA path yet: the
-  direct-GL client's own 59,556-byte setup push does not yet resolve/read
-  host-side under its page-directory churn (so its draw sections never open),
-  glxgears' window is black, and X screen-init is a per-boot lottery, so
-  those are the named blockers. The lanes and the ladder are on
+  direct-GL payload VAs (setup push `0x4001004`, draws
+  `0x4250000`/`0x4250110`) still resolve to zero/implausible PAs because
+  their user/UVM VAS is never registered (so its draw sections never open),
+  glxgears' window is black, and X screen-init keeps a per-boot
+  first-generation lottery, so those are the named blockers. The lanes and
+  the ladder are on
   [`Graphics-Execution.md`](Graphics-Execution.md).
 
 ## 6. Portability
diff --git a/wiki/FAQ.md b/wiki/FAQ.md
index 5aa4fa3..e357649 100644
--- a/wiki/FAQ.md
+++ b/wiki/FAQ.md
@@ -5,7 +5,7 @@
 > [`../docs/09-reference/glossary-and-faq.md`](../docs/09-reference/glossary-and-faq.md);
 > the docs tree wins on disagreement.
 
-Status: 2026-11-12, tree `master @ 800c108f`.
+Status: 2026-11-13, tree `master @ 436cbf9d`.
 
 ## Project and positioning
 
@@ -46,12 +46,16 @@ renders ~520 FPS), the 2D path is green and the DDX 3D replay executes. The
 `pixel=ff0000ff`, the off-screen path produced 500/500 non-black animated
 frames per run, and videos were captured (45.4 s on 2026-11-11, 50 s on
 2026-11-12). GZDoom reaches `V_Init: allocate screen` with its GL 4.6.0
-context on an even modeNum. Window and screen pixels are still the wall: the
-direct-GL client's 59,556-byte setup push does not yet resolve/read host-side
-under its page-directory churn (so its draws never reach the engine),
-glxgears' window is black, and X screen-init is a per-boot lottery. The guest
-Vulkan pipeline runs end to end (device → command buffer → fence → readback)
-but frames are black. See
+context on an even modeNum. The X DDX idle-DMA/ScreenInit, USERD-latch,
+re-probe, kernel-mode-spin and flip-event walls were closed (X green >10
+minutes), captured GL sections now execute on the engine, and the client's
+push bodies decode as real GR method streams above 10 GiB. Window and screen
+pixels are still the wall: the direct-GL payload VAs (the `0x4001004` setup
+push and the `0x4250000`/`0x4250110` draws) resolve to zero/implausible PAs
+because their user/UVM VAS is never registered, so its draws never reach the
+engine; glxgears' window is black, and X screen-init keeps a per-boot
+first-generation lottery. The guest Vulkan pipeline runs end to end (device
+→ command buffer → fence → readback) but frames are black. See
 [`OpenGL.md`](OpenGL.md), [`Vulkan.md`](Vulkan.md) and
 [`Graphics-Execution.md`](Graphics-Execution.md).
 
diff --git a/wiki/Graphics-Execution.md b/wiki/Graphics-Execution.md
index 38eab6c..107044c 100644
--- a/wiki/Graphics-Execution.md
+++ b/wiki/Graphics-Execution.md
@@ -12,7 +12,7 @@
 > [`../docs/04-implementation/04-real-render-walls.md`](../docs/04-implementation/04-real-render-walls.md)
 > (the measured walls); the docs tree wins on disagreement.
 
-Status: 2026-11-12, tree `master @ 800c108f`. Tags: `[live]` observed end to
+Status: 2026-11-13, tree `master @ 436cbf9d`. Tags: `[live]` observed end to
 end; `[wip]` partially built; `[wall]` current blocker; `[target]` defined
 success state; `[planned]` designed, not built.
 
@@ -89,10 +89,20 @@ fidelity:
    ring/VAS anchor and USERD machinery are substantially hardened (verified
    page-directory discovery, per-rank content scans, eager push pins,
    client-allocated USERD resolution, foreign-USERD skip, aperture-aware
-   fallback, wrapped-PUT acceptance). What remains for the client's own
-   stream is **delivery**: its 59,556-byte setup push (GPU VA `0x4024004`) is
-   still not resolvable/readable host-side while the client's page-directory
-   incarnation churns, so no draw section opens and the window stays black;
+   fallback, wrapped-PUT acceptance), and the 11-12/11-13 wave closed the X
+   side of the path: the DDX idle-DMA/ScreenInit wall, the USERD-latch
+   lifetime, the same-pass re-probe thrash, the post-ScreenInit Xorg
+   kernel-mode spin (a display-engine GET-past-PUT on a driver ring wrap) and
+   the flip-event timeout are all fixed, and captured GL sections now
+   execute on the engine (`GR LAUNCH submitted` / `GUEST GR LAUNCH OK`) with
+   the data window populated (`n_data` 0 -> 1024). What remains for the
+   client's own stream is **delivery**: the lookalike gate and the live-PA
+   bound fix (10 GiB raised to the registered guest-RAM top, 14 GiB) let the
+   client's 13+ GiB page directories walk and decode real GR method streams
+   (impossible before), but the GL setup push (59,556 bytes at VA `0x4001004`)
+   and the draw pushes (`0x4250000`/`0x4250110`) still resolve to
+   zero/implausible PAs because their user/UVM VAS is never registered, so no
+   draw section opens for `0xbeef0100` and the window stays black;
    window/screen present is still the frontier (§6).
 
 ## 4. The channel and object picture
@@ -150,10 +160,11 @@ swaps, and the GR backend no longer times out (the pair-close/pair-safe
    zero), the DDX 3D replay renders and reads back a pbuffer pixel
    (`pixel=ff0000ff`), the off-screen frame path produced non-black animated
    frames and captured videos (45.4 s and 50 s), the RM write-lock holder
-   (Xorg in the DDX vidheap scrub wait) is fixed (`df6e71bb`), and the
-   direct-GL ring/USERD machinery is hardened. The next step is delivering the
-   direct-GL client's own **setup push** (59,556 bytes at VA `0x4024004`) and
-   then the window/screen present path.
+   (Xorg in the DDX vidheap scrub wait) is fixed (`df6e71bb`), the X
+   DDX/ScreenInit stability walls are closed, and the direct-GL ring/USERD
+   machinery is hardened. The next step is delivering the direct-GL payload
+   (setup push at VA `0x4001004`, draws at `0x4250000`/`0x4250110`) by
+   registering its user/UVM VAS, and then the window/screen present path.
 
 During bring-up the module also carries a **diagnostics-only mirror** for apps
 that spin on a shared progress word; it exists so a run can proceed while the
@@ -162,32 +173,46 @@ requires it switched off, along with any external poke.
 
 ## 6. Where the frontier is (ranked walls)
 
-1. **Direct-GL command-stream delivery** `[wall]`. The direct-GL ring/VAS
-   anchor is substantially hardened (verified-pair page-directory discovery,
-   per-rank content scans, eager push pins at the ring latch, client-allocated
-   USERD resolution with a foreign-USERD skip, aperture-aware wire fallback and
-   wrapped-PUT acceptance), but the client's own **59,556-byte setup push**
-   (GPU VA `0x4024004`) is still not resolvable or readable host-side while
-   the client's page-directory incarnation churns — the pages live in the
-   emulated FB aperture beyond the visible window, and the CE ring sibling
-   (`0xbeef0101`) resolves only intermittently. Until the setup push decodes,
-   no GL draw section opens and no `GR LAUNCH` is submitted for the direct
-   client: GZDoom spins in its GL pipeline after `V_Init` and the window stays
-   black.
+1. **Direct-GL command-stream delivery** `[wall]`. The ring/VAS anchor, the
+   lookalike gate (a dense repeating-pointer page is refused) and the live-PA
+   bound are now right: the bound was raised from a compile-time 10 GiB to the
+   registered guest-RAM top (14 GiB on the 12 GiB boots), so the client's
+   parked page directory at 13+ GiB walks and push bodies decode as **real GR
+   method streams** (`src=4 plausible=1`, e.g. `SET_SUBDEVICE_MASK` +
+   `LAUNCH_DMA`) — reads that were impossible before. The exact remaining gap
+   is registration: the GL setup push (59,556 bytes at VA `0x4001004`) and the
+   draw pushes (`0x4250000`/`0x4250110`) still resolve to zero/implausible
+   PAs, and a walk probe during `gl_frames` shows **no registered VAS maps
+   them** — the payloads live in the client's user/UVM VAS, which the service
+   never registers. Until that VAS is registered (or the payload set pinned
+   from the guest pagemap), no GL draw section opens for `0xbeef0100` and the
+   window stays black. Related finding: the engine-zero-write campaign showed
+   the store wall is upstream of the draw — the replayed 221-word window
+   contains no draw, and the front end was parking on a pre-poisoned CWD only
+   because of that (the CWD-clear fixes landed as hygiene, not as the cause).
 2. **Window/screen present** `[wall]`. The pbuffer and off-screen frame paths
    are proven (`pixel=ff0000ff`, 500/500 non-black frames, captured videos),
    but a windowed present does not land: glxgears' window is black, the DDX
    shared-surface `gpuRefCount`/`lastKickoffRefCount` poll (W1) must be
    satisfied through a verified surface VA, and a synchronous window draw
    wedges X.
-3. **X screen-init and stability** `[wall]`. X startup is still a per-boot
-   lottery: the DDX can fail its idle-DMA check (`Failed to idle DMA` ->
-   `Failed to allocate notification memory` -> `Failed to allocate push
-   buffer` -> `ScreenInit failed`), and the shared nvClip `modeNum` must be
-   even for the GL client's state init to succeed (an odd value is guest
-   userspace X-driver state, cleared by one X restart — not a host bug).
-   Wrapped PUTs and the kick-idle marker/GET publication are handled; a guest
-   kernel panic after a wedge is recovered by an offline filesystem check.
+3. **X screen-init and stability** `[wip]` (was `[wall]`). The idle-DMA/
+   ScreenInit class, the USERD-latch lifetime, the same-pass re-probe thrash,
+   the post-ScreenInit Xorg kernel-mode spin (display-engine GET-past-PUT on a
+   driver ring wrap) and the flip-event timeout are fixed, and X has stayed
+   green for >10 minutes in a validated window. What remains is a per-boot
+   **first-generation lottery**: only an X started immediately after boot
+   passes the DDX DMA init (3/7 windows), later DMA instances can still fail,
+   and the shared nvClip `modeNum` must be even for the GL client's state init
+   (an odd value is guest userspace X-driver state, cleared by one X restart —
+   not a host bug). Wrapped PUTs and the kick-idle marker/GET publication are
+   handled; a guest kernel panic after a wedge is recovered by an offline
+   filesystem check.
+4. **Non-black window frames and sustained rate** `[wall]`/`[target]`. Once
+   the command-stream delivery, the window/screen present and X screen-init
+   land, the capture must show motion in a window, then 60 fps in one VM with
+   no forcing, then two VMs on two mediated devices with non-black frames in
+   both.
 4. **Non-black window frames and sustained rate** `[wall]`/`[target]`. Once
    the command-stream delivery, the window/screen present and X screen-init
    land, the capture must show motion in a window, then 60 fps in one VM with
@@ -213,15 +238,18 @@ requires it switched off, along with any external poke.
 | Direct-GL GR ring `0xbeef0100` resolves; releases advance; ring/VAS anchor hardened (verified page-directory discovery, eager push pins, per-rank scans) | `[live]` |
 | Client-allocated USERD resolved from the channel's memory objects (`hUserdMemory`/`userdOffset`); foreign-USERD adoption skipped; aperture-aware wire fallback | `[live]` |
 | Guest adapter init with the all-sysmem instance configuration (`RMInstLoc`) — the BAR2-verify trap | `[live]` |
+| X DDX idle-DMA/ScreenInit, USERD-latch lifetime, re-probe thrash, Xorg kernel-mode spin (GET-past-PUT) and flip-event walls closed; X green for >10 minutes (`13a0c5d6`, `acb51d53`, `6ebc7cd4`, `770d6b4a`, `b9213c57`, `29690635`) | `[live]` |
+| Captured GL sections execute on the engine (`GR LAUNCH submitted` / `GUEST GR LAUNCH OK`); data window populated (`n_data` 0 -> 1024) | `[live]` |
+| Client push bodies decode as real GR method streams above 10 GiB through the VAS walk (live-PA bound raised to the registered guest-RAM top, `436cbf9d`; lookalike gate `7d27df77`) | `[live]` |
 | GZDoom passes `V_Init: allocate screen` with GL 4.6.0 when shared nvClip `modeNum` is even | `[live]` |
 | RM write-lock holder identified (Xorg in the DDX vidheap scrub wait) and fixed (`df6e71bb`) | `[live]` |
 | GL section capture: the X channel's `0xC597` stream decoded | `[live]` |
 | Verbatim 3D method-stream replay retired by the engine (no MMU fault) | `[live]` |
 | Synthesized launch executes real `sm_75` SASS; Turing `V3` program header accepted | `[live]` |
 | Emulated FB/GART sizing traps fixed (FB info replies in KB; GART default 256 MiB), removing the 4 GiB guest-allocation class | `[live]` |
-| Direct-GL command-stream delivery (the 59,556-byte setup push at VA `0x4024004`; the CE ring `0xbeef0101`) | `[wall]` |
+| Direct-GL command-stream delivery (gl setup push at VA `0x4001004` and draws at `0x4250000`/`0x4250110`; the CE ring `0xbeef0101`) | `[wall]` — the payloads' user/UVM VAS is never registered, so they resolve to zero/implausible PAs and no section opens for `0xbeef0100` |
 | Window/screen present produces non-black window pixels | `[wall]` |
-| X screen-init/stability (idle-DMA ScreenInit lottery, modeNum parity) | `[wall]` |
+| X screen-init first-generation lottery (`modeNum` parity; only an immediately-post-boot X passes DDX DMA init) | `[wip]` |
 | Non-black screen pixels from the emulated vGPU's 3D pipeline | `[wall]` |
 | Windows/DirectX guests | `[planned]` |
 
@@ -235,8 +263,12 @@ requires it switched off, along with any external poke.
 * Display/KMS bring-up (NvKms, `/dev/dri`, X, a real GL context) is not a
   rendered-frame claim. GZDoom reaching `V_Init: allocate screen` proves the
   client's GL init and the direct-GL GR lane, not the game loop or a
-  presented frame; the direct-GL setup push does not yet decode, so the
+  presented frame; the direct-GL payload VAS is not registered, so the
   client's draws do not reach the engine.
+* The engine-zero-write (NOWRITE) campaign is not a rendering result: it
+  proved the replay window it inspected carried no draw, and that the front
+  end was parking on a pre-poisoned CWD only as a consequence; the store wall
+  is upstream in push delivery, not a 3D-pipeline defect.
 * No frame-rate or latency numbers: the scheduled measurement is defined
   (60 fps over 60 s, no forcing) but not yet met.
 
diff --git a/wiki/Host-Module.md b/wiki/Host-Module.md
index 1fc6ee1..651b1bd 100644
--- a/wiki/Host-Module.md
+++ b/wiki/Host-Module.md
@@ -6,7 +6,7 @@
 > source: [`../docs/03-architecture/06-host-module-and-hybrid-model.md`](../docs/03-architecture/06-host-module-and-hybrid-model.md);
 > the docs tree wins on disagreement with this page.
 >
-> Status: 2026-11-12, tree `master @ 800c108f`. Tags: `[live]` observed with
+> Status: 2026-11-13, tree `master @ 436cbf9d`. Tags: `[live]` observed with
 > the stock guest driver; `[wip]` demonstrated live, being productized;
 > `[gated]` implemented default-off behind supervised gates; `[wall]` known
 > blocking limit; `[target]` designed, not built; `[planned]` roadmap.
@@ -130,13 +130,14 @@ completion. The DDX 3D replay renders and reads back a pbuffer pixel
 animated frames per run and captured videos (45.4 s and 50 s), the RM
 write-lock holder (Xorg in the DDX vidheap scrub wait) is fixed
 (`df6e71bb`), X and the stock GLX path are fully green (`glxinfo -B` rc 0,
-~520 FPS `glxgears`), and the direct-GL ring/VAS and USERD machinery is
+~520 FPS `glxgears`), the X DDX/ScreenInit stability walls are closed (X
+green >10 minutes), and the direct-GL ring/VAS and USERD machinery is
 hardened (verified page-directory discovery, eager push pins,
 client-allocated USERD resolution, foreign-USERD skip). The remaining GL gap
-is delivery of the direct-GL client's own setup push (59,556 bytes at VA
-`0x4024004` — not yet resolvable/readable host-side under the client's
-page-directory churn) and the window/screen present path, which currently
-stays black or wedges X.
+is delivery of the direct-GL payload (setup push at VA `0x4001004`, draws at
+`0x4250000`/`0x4250110` — their user/UVM VAS is never registered, so they
+resolve to zero/implausible PAs) and the window/screen present path, which
+currently stays black or wedges X.
 
 ## 6. Debug parameters
 
diff --git a/wiki/OpenGL.md b/wiki/OpenGL.md
index 0bcaae7..e9a1750 100644
--- a/wiki/OpenGL.md
+++ b/wiki/OpenGL.md
@@ -12,7 +12,7 @@
 > [`../docs/03-architecture/02-guest-stack-and-cudasw.md`](../docs/03-architecture/02-guest-stack-and-cudasw.md)
 > (the guest stack). The docs tree wins on disagreement.
 
-Status: 2026-11-12, tree `master @ 800c108f`. Tags: `[live]` observed with the
+Status: 2026-11-13, tree `master @ 436cbf9d`. Tags: `[live]` observed with the
 stock guest driver; `[wip]` partial; `[wall]` current blocker; `[target]`
 defined success state.
 
@@ -86,14 +86,17 @@ Rated honestly, against the milestone ladder in the plan:
 | First non-black GPU-rendered frames: 500/500 off-screen 640x480 frames per run; 45.4 s video (`r1769`) and a 50 s capture (2026-11-12) | `[live]` |
 | Direct-GL GR ring `0xbeef0100` resolves; releases advance; ring/VAS anchor hardened (verified page-directory discovery, eager push pins, per-rank scans) | `[live]` |
 | Client-allocated USERD resolved from the channel's memory objects (`hUserdMemory`/`userdOffset`); foreign-USERD adoption skipped; aperture-aware wire fallback | `[live]` |
+| X DDX idle-DMA/ScreenInit, USERD-latch lifetime, re-probe thrash, Xorg kernel-mode spin (GET-past-PUT) and flip-event walls closed; X green >10 minutes (`13a0c5d6`, `acb51d53`, `6ebc7cd4`, `770d6b4a`, `b9213c57`, `29690635`) | `[live]` |
+| Captured GL sections execute on the engine (`GR LAUNCH submitted` / `GUEST GR LAUNCH OK`); data window populated (`n_data` 0 -> 1024) | `[live]` |
+| Client push bodies decode as real GR method streams above 10 GiB via the VAS walk (live-PA bound raised to the registered guest-RAM top, `436cbf9d`) | `[live]` |
 | GZDoom passes `V_Init: allocate screen` with GL 4.6.0 when shared nvClip `modeNum` is even | `[live]` |
 | RM write-lock holder identified (Xorg in the DDX vidheap scrub wait) and fixed (`df6e71bb`) | `[live]` |
 | Engine executes a launch built from the captured section (real `sm_75` SASS retired) | `[live]` |
 | Verbatim 3D method-stream replay retired by the engine, no MMU fault | `[live]` |
 | Emulated FB/GART sizing traps fixed (FB info replies in KB; GART default 256 MiB), removing the 4 GiB guest-allocation class | `[live]` |
-| Direct-GL command-stream delivery (the 59,556-byte setup push at VA `0x4024004`; the CE ring `0xbeef0101`) | `[wall]` |
+| Direct-GL command-stream delivery (gl setup push at VA `0x4001004` and draws at `0x4250000`/`0x4250110`; the CE ring `0xbeef0101`) | `[wall]` — the payloads' user/UVM VAS is never registered; they resolve to zero/implausible PAs and no section opens for `0xbeef0100` |
 | Window/screen present produces non-black screen pixels | `[wall]` |
-| X screen-init/stability (idle-DMA ScreenInit lottery, modeNum parity) | `[wall]` |
+| X screen-init first-generation lottery (`modeNum` parity; only an immediately-post-boot X passes DDX DMA init) | `[wip]` |
 | 60 fps sustained, no forcing (M-GL4) | `[target]` |
 
 ## 4. How OpenGL runs are verified
@@ -115,13 +118,17 @@ non-black through the mdev), M-GL4 (60 fps, no forcing), M-GL5 (two VMs, two
 mdevs), M-GL6 (split-screen video). The project sits **between M-GL1 and
 M-GL2, with M-GL2's off-screen half proven**: the display/KMS stack registers,
 X and the stock GLX path are fully green (`glxinfo -B` rc 0, ~520 FPS
-`glxgears`, Xorg WAIT 0), the direct-GL ring/USERD machinery is hardened, and
-the GPU-rendered pbuffer path produced non-black animated frames and captured
-videos (45.4 s and 50 s). The remaining gates are **delivery of the direct-GL
-client's own command stream** (its 59,556-byte setup push is not yet
-resolvable/readable host-side under the client's page-directory churn), the
-window/screen present path (glxgears' window is black and a window draw can
-wedge X), and X screen-init stability — then the first rendered screen frame.
+`glxgears`, Xorg WAIT 0), the DDX/X-stability walls were closed (X green for
+more than 10 minutes), the direct-GL ring/USERD machinery is hardened, and the
+GPU-rendered pbuffer path produced non-black animated frames and captured
+videos (45.4 s and 50 s). Captured GL sections now execute on the engine and
+the client's push bodies decode as real GR method streams above 10 GiB. The
+remaining gates are **delivery of the direct-GL client's own command stream**
+(the setup push at `0x4001004` and the draws at `0x4250000`/`0x4250110` still
+resolve to zero/implausible PAs because their user/UVM VAS is never
+registered), the window/screen present path (glxgears' window is black and a
+window draw can wedge X), and the X first-generation screen-init lottery —
+then the first rendered screen frame.
 
 ## 6. What is not claimed
 
@@ -129,9 +136,9 @@ wedge X), and X screen-init stability — then the first rendered screen frame.
   vGPU yet; every screen capture so far is black. The non-black frames and the
   videos (45.4 s and 50 s) come from the off-screen pbuffer path (pbuffer ->
   sysmem -> kvmfr ivshmem -> host reader), not from a windowed X screen
-  capture. The direct-GL client's setup push does not yet decode, its draws do
-  not reach the engine, a synchronous window draw wedges X, and X screen-init
-  is a per-boot lottery. Those are the current walls.
+  capture. The direct-GL payload VAS is not registered, its draws do not reach
+  the engine, a synchronous window draw wedges X, and X screen-init retains a
+  per-boot first-generation lottery. Those are the current walls.
 * GZDoom reaching `V_Init: allocate screen` is not a rendered-frame claim; it
   proves the client's GL init and the direct-GL GR lane, not the game loop or
   a presented frame.
diff --git a/wiki/Physical-GPU-Backend.md b/wiki/Physical-GPU-Backend.md
index bfd89bf..1f82bdf 100644
--- a/wiki/Physical-GPU-Backend.md
+++ b/wiki/Physical-GPU-Backend.md
@@ -5,7 +5,7 @@
 > guest-facing emulation. Canonical sources: [`../docs/03-architecture/08-physical-gpu-integration.md`](../docs/03-architecture/08-physical-gpu-integration.md)
 > and [`../docs/03-architecture/11-physical-backend-guest-wiring.md`](../docs/03-architecture/11-physical-backend-guest-wiring.md); the docs tree wins on disagreement.
 
-Status: 2026-11-12, tree `master @ 800c108f`. Tags: `[live]` proven with the
+Status: 2026-11-13, tree `master @ 436cbf9d`. Tags: `[live]` proven with the
 stock guest driver; `[gated]` implemented default-off; `[wip]` partially
 built; `[wall]` current blocker; `[target]` planned end state.
 
@@ -109,7 +109,7 @@ FAIL  a failed mutating operation parks the device in a locked fail-safe;
 | Host RM client and first real engine work (static config, real objects, 4 KiB CE copy) | done `[live]` |
 | Guest-copy forwarding, deferred release, hardware-primary copies, engine-authored relay, fault relay | verified live (seams parameterised and fail-open); the staged-transfer class is under repair `[live]` |
 | CUDA kernel execution (`vectorAdd` and further clients) | done `[live]` — stock guest CUDA clients (vector-add, matrix-multiply, transformer) execute on the physical engine with verified results and engine-authored completions relayed to the guest |
-| Graphics method-stream execution (verbatim 3D replay, synthesized launches, direct-GL client channels) | `[wip]` — the engine retires real graphics streams, the display/KMS stack registers and X + stock GLX are green, and the first non-black GPU-rendered frames are captured off-screen; delivery of the direct-GL client's own command stream and the window/screen present are the frontier ([`Graphics-Execution.md`](Graphics-Execution.md)) |
+| Graphics method-stream execution (verbatim 3D replay, synthesized launches, direct-GL client channels) | `[wip]` — the engine retires real graphics streams, the display/KMS stack registers and X + stock GLX are green (the DDX/ScreenInit stability walls are closed, X green >10 minutes), captured GL sections execute, and the first non-black GPU-rendered frames are captured off-screen; registration of the direct-GL payload user/UVM VAS (setup/draw pushes still resolve to zero/implausible PAs) and the window/screen present are the frontier ([`Graphics-Execution.md`](Graphics-Execution.md)) |
 
 ## 7. The execution frontier
 
@@ -123,12 +123,15 @@ same machinery in three shapes (a verbatim 3D method-stream replay,
 synthesized launches, and the direct GL client's own GR/CE channels); the
 captured and synthesized streams execute on the engine, and the direct GL
 client's ring/USERD machinery is hardened. The display/KMS stack registers,
-the X DDX waits are fixed, X and the stock GLX path are fully green
-(`glxinfo -B` rc 0, ~520 FPS `glxgears`), the DDX 3D replay executes, and the
-first non-black GPU-rendered frames are proven (500/500 off-screen frames per
-run plus captured videos); the remaining graphics gates are delivery of the
-direct-GL client's own 59,556-byte setup push, the window/screen present, and
-X screen-init stability before non-black window pixels. The remaining
+the X DDX waits are fixed (the idle-DMA/ScreenInit, USERD-latch, re-probe,
+kernel-mode-spin and flip-event walls are closed, X green >10 minutes), X and
+the stock GLX path are fully green (`glxinfo -B` rc 0, ~520 FPS `glxgears`),
+the DDX 3D replay executes, captured GL sections execute on the engine, and
+the first non-black GPU-rendered frames are proven (500/500 off-screen frames
+per run plus captured videos); the remaining graphics gates are registration
+of the direct-GL payload user/UVM VAS (setup/draw pushes still resolve to
+zero/implausible PAs), the window/screen present, and the X first-generation
+screen-init lottery before non-black window pixels. The remaining
 compute work is the staged-transfer class (under repair), the every-boot
 acceptance campaign, and per-guest execution isolation — see
 [`Execution-Frontier.md`](Execution-Frontier.md) and
diff --git a/wiki/Project-Goals.md b/wiki/Project-Goals.md
index b41797a..5222947 100644
--- a/wiki/Project-Goals.md
+++ b/wiki/Project-Goals.md
@@ -10,7 +10,7 @@
 > [`Execution-Frontier.md`](Execution-Frontier.md) and
 > [`Graphics-Execution.md`](Graphics-Execution.md).
 
-Status: 2026-11-12, tree `master @ 800c108f`. Tags: `[live]` working with the
+Status: 2026-11-13, tree `master @ 436cbf9d`. Tags: `[live]` working with the
 stock guest driver; `[wip]` in progress; `[planned]` designed, not built;
 `[target]` bring-up ahead; `[non-goal]` explicitly out of scope.
 
@@ -46,12 +46,12 @@ drivers, no license.**
 
 ## 3. Goals and their status
 
-| Goal | What success looks like | Status (2026-11-12) |
+| Goal | What success looks like | Status (2026-11-13) |
 |---|---|---|
 | Stock guest driver initialisation | The unmodified driver probes, initialises and enumerates as on bare metal (`nvidia-smi`) | `[live]` — TU104 reference platform |
 | Full CUDA driver-API surface | Context creation, allocation, copies, free, destroy complete with correct results | `[live]` — the driver-API smoke prints `ALL OK`; the 64-byte payload round-trips |
 | CUDA kernel execution on real hardware | Verified guest kernels execute on the physical GPU, with engine-authored completions waking the guest | `[live]` — vector-add, matrix-multiply and transformer clients green on fresh boots; the staged-transfer class, the every-boot acceptance campaign and per-guest isolation are in progress ([`Execution-Frontier.md`](Execution-Frontier.md)) |
-| OpenGL (3D graphics) | Stock guest GL applications render real pixels through the emulated vGPU | `[wip]` — the display/KMS stack and X run, the stock NVIDIA GLX path is fully green (`glxinfo -B` rc 0, OpenGL 4.6.0 direct, `glxgears` ~520 FPS), the 2D path is green, the DDX 3D replay executes, and the first non-black GPU-rendered frames plus captured videos (45.4 s and 50 s) are proven off-screen; GZDoom reaches `V_Init`. Window/screen pixels remain the frontier: the direct-GL client's 59,556-byte setup push does not yet resolve/read host-side under its page-directory churn (so its draws never reach the engine), the window/screen present is unproven, and X screen-init is a per-boot lottery ([`OpenGL.md`](OpenGL.md)) |
+| OpenGL (3D graphics) | Stock guest GL applications render real pixels through the emulated vGPU | `[wip]` — the display/KMS stack and X run, the stock NVIDIA GLX path is fully green (`glxinfo -B` rc 0, OpenGL 4.6.0 direct, `glxgears` ~520 FPS), the 2D path is green, the DDX 3D replay executes, the X DDX/ScreenInit stability walls are closed (X green >10 minutes), captured GL sections execute on the engine, and the first non-black GPU-rendered frames plus captured videos (45.4 s and 50 s) are proven off-screen; GZDoom reaches `V_Init`. Window/screen pixels remain the frontier: the direct-GL payload VAs (setup push `0x4001004`, draws `0x4250000`/`0x4250110`) resolve to zero/implausible PAs because their user/UVM VAS is never registered, so its draws never reach the engine; the window/screen present is unproven, and X screen-init keeps a first-generation lottery ([`OpenGL.md`](OpenGL.md)) |
 | Vulkan | Stock guest Vulkan applications render real pixels | `[wip]` — the pipeline runs end to end (device → command buffer → fence → readback); frames are black — program delivery and program-VA mapping are the frontier ([`Vulkan.md`](Vulkan.md)) |
 | Windows guests (DirectX, CUDA) | A stock WDDM driver and stock D3D/CUDA applications run in Windows guests | `[target]` — not started; same emulation target ([`DirectX.md`](DirectX.md)) |
 | Video (NVENC/NVDEC) | Encode/decode through the emulated device | `[planned]` |
diff --git a/wiki/Project-Plan.md b/wiki/Project-Plan.md
index 1d3a7d1..0300b78 100644
--- a/wiki/Project-Plan.md
+++ b/wiki/Project-Plan.md
@@ -15,7 +15,7 @@
 > [`../docs/06-portability/03-device-validation-and-porting-sequence.md`](../docs/06-portability/03-device-validation-and-porting-sequence.md);
 > the docs tree wins on disagreement.
 
-Status: 2026-11-12, tree `master @ 800c108f`. Tags: `[done]`, `[active]`,
+Status: 2026-11-13, tree `master @ 436cbf9d`. Tags: `[done]`, `[active]`,
 `[ahead]` — the plan's own state vocabulary, distinct from the goal tags.
 
 ## 1. How the plan works
@@ -40,11 +40,11 @@ itself:
 
 ## 2. The phases
 
-| Phase | What it delivers | Exit gate | State (2026-11-11) |
+| Phase | What it delivers | Exit gate | State (2026-11-13) |
 |---|---|---|---|
 | **P0 — Platform** | Emulated vGPU device, GSP boot and GSP-RM emulation, stock guest driver initialisation | Driver-API smoke green (`ALL OK`) = evaluation rung 2 | `[done]` |
 | **P1 — First execution (compute)** | Guest CUDA kernels executing on the physical GPU, with engine-authored completions; then hardening | Verified clients + engine-authored completion = rung 3 core; hardening: staged-transfer class, every-boot acceptance, per-guest isolation | `[active]` — execution green; hardening in progress |
-| **P2 — Graphics execution** | OpenGL/Vulkan draw commands executed by the physical 3D pipeline and delivered as readable pixels | The graphics ladder: M-GL1 client context-init executes; M-GL2 `glxgears` non-black; M-GL3 GZDoom GL non-black through the mdev | `[active]` — between M-GL1 and M-GL2 with M-GL2's off-screen half proven: the display/KMS and DDX replay machinery work, X + stock GLX are green, the first non-black GPU-rendered frames and videos are captured, and the direct-GL ring/USERD machinery is hardened; delivery of the direct-GL client's own setup push, the window/screen present and X screen-init stability are the walls |
+| **P2 — Graphics execution** | OpenGL/Vulkan draw commands executed by the physical 3D pipeline and delivered as readable pixels | The graphics ladder: M-GL1 client context-init executes; M-GL2 `glxgears` non-black; M-GL3 GZDoom GL non-black through the mdev | `[active]` — between M-GL1 and M-GL2 with M-GL2's off-screen half proven: the display/KMS and DDX replay machinery work, X + stock GLX are green, the first non-black GPU-rendered frames and videos are captured, the X DDX/ScreenInit stability walls are closed, captured GL sections execute on the engine, and direct-GL push bodies decode above 10 GiB; the remaining walls are registration of the direct-GL payload user/UVM VAS (setup/draw pushes still resolve to zero/implausible PAs), the window/screen present, and the X first-generation screen-init lottery |
 | **P3 — Sustained and multi-tenant** | Frame rates without assistance; multiple VMs sharing the GPU with measured fairness; soak-stable operation | Graphics M-GL4 (60 fps, no forcing) and M-GL5 (two VMs, two mdevs); CUDA battery + soak; per-guest execution isolation = rungs 4/5 | `[ahead]` |
 | **P4 — Breadth** | Video (NVENC/NVDEC), Windows/DirectX guests, live migration, non-KVM hypervisor transports | Per-case bring-up gates plus the matrix's evidence expectations | `[ahead]` |
 | **P5 — Scale and portability** | New GPU generations and driver families carried forward; published performance programme | A profile + measured delta per version, validated on hardware; A/B numbers published per the measurement contract | `[ahead]` |
@@ -59,15 +59,17 @@ Ranked, in dependency order:
 
 1. **Graphics pixels (P2).** The client and display stacks execute, X and the
    stock GLX path are fully green (`glxinfo -B` rc 0, ~520 FPS `glxgears`),
-   the DDX 3D replay runs, the first non-black GPU-rendered frames and videos
-   are captured off-screen, and the direct-GL ring/USERD machinery is
-   hardened. The named walls are **delivery of the direct-GL client's own
-   command stream** (its 59,556-byte setup push is not yet resolvable/
-   readable host-side under the client's page-directory churn, so no draw
-   section opens and GZDoom spins after `V_Init`), the window/screen present
-   path (glxgears' window is black and a window draw wedges X), X screen-init
-   stability (the DDX idle-DMA ScreenInit lottery; even `modeNum` required),
-   and then non-black window frames. Full detail:
+   the X DDX/ScreenInit stability walls are closed (X green >10 minutes), the
+   DDX 3D replay runs, the first non-black GPU-rendered frames and videos are
+   captured off-screen, captured GL sections execute on the engine, and the
+   direct-GL push bodies decode as real GR method streams above 10 GiB. The
+   named walls are **registration of the direct-GL payload user/UVM VAS**
+   (the `0x4001004` setup push and `0x4250000`/`0x4250110` draws still resolve
+   to zero/implausible PAs, so no draw section opens for `0xbeef0100` and
+   GZDoom spins after `V_Init`), the window/screen present path (glxgears'
+   window is black and a window draw wedges X), the X first-generation
+   screen-init lottery (even `modeNum` required), and then non-black window
+   frames. Full detail:
    [`Graphics-Execution.md`](Graphics-Execution.md) §6.
 2. **Compute hardening (P1).** The staged-transfer class (failure modes proven,
    fixes in flight); the every-boot acceptance campaign; per-guest execution
diff --git a/wiki/Project-Status.md b/wiki/Project-Status.md
index 8d34d70..3e7c54f 100644
--- a/wiki/Project-Status.md
+++ b/wiki/Project-Status.md
@@ -10,7 +10,7 @@
 > (the execution frontier). When this page and the docs disagree, the docs tree
 > wins.
 
-Status: 2026-11-12, tree `master @ 800c108f`. Tags: `[live]` proven with the
+Status: 2026-11-13, tree `master @ 436cbf9d`. Tags: `[live]` proven with the
 stock guest driver; `[gated]` implemented, default-off or behind supervised
 gates; `[wip]` partially implemented; `[wall]` current blocker; `[target]`
 named success state; `[planned]` designed, not built.
@@ -26,9 +26,9 @@ named success state; `[planned]` designed, not built.
 | CUDA userspace init and the driver-API smoke (`cuInit`, device enumeration, `cuCtxCreate`, allocation, copies, free, destroy) | `[live]` working — the smoke prints `ALL OK` and the 64-byte payload round-trips exactly |
 | Guest CUDA kernel execution on real hardware | `[live]` working — verified green on fresh boots: the vector-add (`VADD n=32768 bad=0`), matrix-multiply (`MATMUL n=256 bad=0`) and transformer (`dh=256 seq=64 bad=0`, `FFN4 layers=4 bad=0`) clients print `STATUS OK`, engine-authored completions relay to the guest and its synchronisation waits resolve. A ring-block ownership defect that could stall the first client after a reboot was root-caused and fixed. Remaining: the staged-transfer class (some large multi-chunk clients still mis-verify; the failure modes are proven and under repair) and per-guest execution isolation for simultaneous CUDA guests |
 | Physical backend on real hardware (module-owned GPU running its real GSP-RM) | `[live]` boot, RPC session, object creation, copy-engine work and GR execution proven — the verified guest CUDA kernel clients execute through this backend, and graphics method streams execute on the engine ([`Graphics-Execution.md`](Graphics-Execution.md)) |
-| Display and KMS on the emulated vGPU (nvidia-modeset/NvKms, `/dev/dri`, X) | `[live]` in the campaign configuration — the emulated display engine serves the guest's display push-buffer channels (notifier plus `UPDATE -> FINISHED`), nvidia-modeset/NvKms registers (`/dev/dri/card0`, `renderD128`, `fb0`), `nvidia-smi -L` enumerates and X settles; the display-capability seam is parameterised ([`Graphics-Execution.md`](Graphics-Execution.md)) |
+| Display and KMS on the emulated vGPU (nvidia-modeset/NvKms, `/dev/dri`, X) | `[live]` in the campaign configuration — the emulated display engine serves the guest's display push-buffer channels (notifier plus `UPDATE -> FINISHED`), nvidia-modeset/NvKms registers (`/dev/dri/card0`, `renderD128`, `fb0`), `nvidia-smi -L` enumerates and X settles. The X DDX idle-DMA/ScreenInit, USERD-latch lifetime, re-probe-thrash, Xorg kernel-mode-spin and flip-event walls were closed in the 11-12/11-13 wave (X green for >10 minutes in a validated window), leaving a per-boot first-generation X lottery (an X started immediately after boot passes DDX DMA init; 3/7 windows); the display-capability seam is parameterised ([`Graphics-Execution.md`](Graphics-Execution.md)) |
 | Multi-tenant isolation (mdev per VM, per-context page directories) | `[wip]` device-level coexistence works — multiple mediated devices with different emulated VRAM sizes and multiple guests coexist (two guests demonstrated); per-guest execution isolation for simultaneous CUDA guests is in progress |
-| OpenGL (3D graphics) | `[wip]` — the display/KMS stack registers, X and the stock NVIDIA GLX path are fully green (`glxinfo -B` returns 0 with OpenGL 4.6.0 and direct rendering; `glxgears` renders ~520 FPS with the emulated GPU's NVIDIA renderer), and the **first non-black GPU-rendered output** is proven: the pbuffer frame path produced 500/500 non-black 640x480 frames per run and captured videos (45.4 s on 2026-11-11; a 50 s 640x480 h264 capture on 2026-11-12). GZDoom reaches `V_Init: allocate screen` with its GL 4.6.0 context whenever the shared nvClip `modeNum` is even. **The frontier is delivery of the direct-GL client's own command stream:** its 59,556-byte setup push is not yet resolvable/readable host-side while the client's page-directory incarnation churns, so its draw sections never reach the engine and the window stays black; the window/screen present path and the X DDX screen-init idle-DMA lottery are the other named blockers ([`OpenGL.md`](OpenGL.md)) |
+| OpenGL (3D graphics) | `[wip]` — the display/KMS stack registers, X and the stock NVIDIA GLX path are fully green (`glxinfo -B` returns 0 with OpenGL 4.6.0 and direct rendering; `glxgears` renders ~520 FPS with the emulated GPU's NVIDIA renderer), and the **first non-black GPU-rendered output** is proven: the pbuffer frame path produced 500/500 non-black 640x480 frames per run and captured videos (45.4 s on 2026-11-11; a 50 s 640x480 h264 capture on 2026-11-12). GZDoom reaches `V_Init: allocate screen` with its GL 4.6.0 context whenever the shared nvClip `modeNum` is even. **The frontier is delivery of the direct-GL client's own command stream:** the lookalike gate and the live-PA-bound fix (10 GiB raised to the registered guest-RAM top, 14 GiB) now let the client's 13+ GiB page directories walk and decode real GR method streams, and its GR ring resolves through its own VAS; but the GL setup push (59,556 bytes at VA `0x4001004`) and the draw pushes (`0x4250000`/`0x4250110`) still resolve to zero/implausible PAs because their user/UVM VAS is never registered, so no draw section opens for `0xbeef0100` and the window stays black. The engine-zero-write campaign showed the store wall is upstream of the draw (the replayed 221-word window is draw-free); the window/screen present path is unproven, and the X screen-init first-generation lottery remains ([`OpenGL.md`](OpenGL.md)) |
 | Vulkan (3D/compute) | `[wip]` — the guest Vulkan pipeline runs end to end on the emulated vGPU (device, allocation, pipeline, command buffer, fence, queue submit, readback) and the engine executes translated launches; frames are still black — program delivery and program-VA mapping are the frontier ([`Vulkan.md`](Vulkan.md)) |
 | DirectX / Windows guests | `[planned]` (target) — no Windows guest booted yet; the architecture is the same emulation target ([`DirectX.md`](DirectX.md)) |
 | Video (NVENC/NVDEC) | `[planned]` |
@@ -80,9 +80,9 @@ with direct rendering, `glxgears` renders ~520 FPS); the first non-black
 GPU-rendered frames are proven off-screen (the pbuffer path produced a
 500-frame 45.4 s video on 2026-11-11 and a 50 s capture on 2026-11-12), and
 GZDoom reaches its screen-allocation stage with GL 4.6.0 on an even modeNum,
-but windowed/screen pixels remain the frontier (the direct-GL client's
-command stream does not yet reach the engine and X screen-init is a per-boot
-lottery) — see
+but windowed/screen pixels remain the frontier (the direct-GL payload VAs
+still resolve to zero/implausible PAs because their user/UVM VAS is never
+registered, and X screen-init keeps a first-generation lottery) — see
 [`OpenGL.md`](OpenGL.md). The
 risc-v-gsp-rm-debugger workbench
 ([`Riscv-GSP-RM-Debugger.md`](Riscv-GSP-RM-Debugger.md)) is the host-side
diff --git a/wiki/System-Overview.md b/wiki/System-Overview.md
index 26da5df..33cf881 100644
--- a/wiki/System-Overview.md
+++ b/wiki/System-Overview.md
@@ -7,7 +7,7 @@
 > and [`../docs/03-architecture/10-interaction-and-scheduling.md`](../docs/03-architecture/10-interaction-and-scheduling.md)
 > for the full picture); the docs tree wins on disagreement.
 
-Status: 2026-11-12, tree `master @ 800c108f`. Tags: `[live]` proven with the
+Status: 2026-11-13, tree `master @ 436cbf9d`. Tags: `[live]` proven with the
 stock guest driver; `[gated]` implemented default-off; `[wip]` partial;
 `[wall]` current blocker; `[target]` designed end state.
 
@@ -142,15 +142,21 @@ RPC from the guest to "firmware":
    buffers and the display notifier/completion (class-aware arm), so
    nvidia-modeset/NvKms registers (`/dev/dri`), X settles and the stock NVIDIA
    GLX path is fully green (`glxinfo -B` rc 0, OpenGL 4.6.0 direct, `glxgears`
-   ~520 FPS); the X DDX waits are fixed, the DDX 3D replay executes, the 2D
-   path is green, the direct-GL ring/USERD machinery is hardened, the first
-   non-black GPU-rendered frames and captured videos (45.4 s and 50 s) are
-   proven off-screen, and the guest Vulkan pipeline runs end to end. The
-   direct-GL client's own setup push still does not resolve/read host-side
-   (so its draws never reach the engine), the window/screen present is
-   unproven (a window draw can wedge X and glxgears' window is black), and X
-   screen-init is a per-boot lottery, so the remaining gate is the window/
-   screen present before the first non-black window frame
+   ~520 FPS); the X DDX waits are fixed (the idle-DMA/ScreenInit, USERD-latch,
+   re-probe, kernel-mode-spin and flip-event walls are closed, and X has stayed
+   green >10 minutes), the DDX 3D replay executes, captured GL sections now
+   execute on the engine, the 2D path is green, the direct-GL ring/USERD
+   machinery is hardened, the first non-black GPU-rendered frames and captured
+   videos (45.4 s and 50 s) are proven off-screen, and the guest Vulkan
+   pipeline runs end to end. The client's push bodies decode as real GR method
+   streams above 10 GiB through the VAS walk, but the direct-GL payload VAs
+   (setup push `0x4001004`, draws `0x4250000`/`0x4250110`) still resolve to
+   zero/implausible PAs because their user/UVM VAS is never registered (so
+   its draws never reach the engine); the window/screen present is unproven
+   (a window draw can wedge X and glxgears' window is black), and X
+   screen-init keeps a first-generation lottery, so the remaining gate is
+   that registration plus the window/screen present before the first
+   non-black window frame
    ([`OpenGL.md`](OpenGL.md), [`Vulkan.md`](Vulkan.md)).
 
 ## 6. Where the detail lives