1 files changed, 33 insertions, 24 deletions
diff --git a/wiki/Execution-Frontier.md b/wiki/Execution-Frontier.md
index 5af5e6d..f24a15a 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-13, tree `master @ 436cbf9d`.
+Status: 2026-11-14, tree `master @ 339da842`.
 Tags: `[live]` observed; `[wip]` partial; `[wall]` current blocker; theories
 are labelled as such.
 
@@ -107,16 +107,22 @@ non-black 640x480 frames per run and captured videos (45.4 s on 2026-11-11, a
 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
-[`Graphics-Execution.md`](Graphics-Execution.md).
+for more than 10 minutes), captured GL sections now execute on the engine, and
+the direct-GL submission is fully decoded: no client push carries a
+method-grammar draw header — the work is macro-driven (data-block blobs plus
+small state pushes invoking MME macros) — and the recycled pushes are now
+recovered, so the client's draw-state push opens a `C597` section, captures,
+and reaches the engine with the golden MME overlay. What is missing is
+**window/screen pixels through the NVIDIA path**: the beef lane's 2799-word
+packed MME program cannot complete inside its <=2048-word block with the
+draw window, so `live_gen` never promotes and the draw never stores
+(`wrote=0`, `px0=0`); the multi-part keep-window mechanism is committed
+default-off with the A/B pending, RT routing was tested and refuted as the
+cause, the `CODESRC` fault-park class is prevented, glxgears' window is
+black, and a synchronous window draw wedges X on some boots. The X
+first-generation start lottery is now the dominant throughput limiter. The
+guest Vulkan pipeline's inline-to-memory upload arm is its gap. The full
+picture lives on [`Graphics-Execution.md`](Graphics-Execution.md).
 
 No breadth beyond these is claimed: Windows guests, migration and performance
 numbers remain planned.
@@ -178,14 +184,16 @@ fully green with glxinfo 4.6.0 and ~520 FPS glxgears, the DDX 3D replay
 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
+ring/USERD machinery is substantially hardened); the direct-GL submission is
+fully decoded (macro-driven; no method-grammar draw header in any push), the
+recycled pushes are recovered, and the client's draw-state push opens,
+captures and reaches the engine. The remaining gap is MME macro completion:
+the beef lane's 2799-word packed program cannot complete inside its
+<=2048-word block with the draw window, so `live_gen` never promotes and the
+draw never stores (RT routing was tested and refuted as the cause; the
+multi-part keep-window A/B is pending). glxgears' window is black, a window
+draw wedges X on some boots, and the X first-generation start lottery is the
+dominant throughput limiter
 ([`Graphics-Execution.md`](Graphics-Execution.md)).
 
 ## 6. Lines of investigation (live)
@@ -200,11 +208,12 @@ first-generation screen-init lottery 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** — 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
+5. **The graphics pixel frontier** — land the MME multi-part keep-window A/B
+   so the beef macro program completes and `live_gen` promotes, verify the
+   store (`wrote>0`) at the bound render target, make the window/screen
+   present land, and reduce the X first-generation start 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