STATE-CURRENT: hourly check-back snapshot (2026-10-02 18:12:01)

1 files changed, 17 insertions, 10 deletions

diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md
index cad25ce..a3605a0 100644
--- a/STATE-CURRENT.md
+++ b/STATE-CURRENT.md
@@ -82,7 +82,7 @@ chain succeeds.
 ## Right now (frontier)
 
 - **GR context campaign: the promote-side wall is root-caused; the current
-  wall is the shared-management GR object alloc (2026-10-02 ~17:10).** The
+  wall is the shared-management GR object alloc (2026-10-02 ~17:35).** The
   long-running context-promote wall was the ladder's virtual address space
   being allocated as *externally owned* (the client owns page tables, VA
   bookings and engine-context commitment), so the server skipped the
@@ -96,15 +96,22 @@ chain succeeds.
   protected region). The same alloc wedges on both the kernel-managed and the
   normal channel variants, so the gate is the server-internal
   context/global-buffer mapping under shared management, not the channel kind
-  or the promote shape. Two supervised wedges in this window were each cleared
-  by an approved reboot (the host is currently held in the locked fail-safe and
-  a further reboot is pending approval). A new untested candidate
-  (kernel-managed channel plus a no-entry virtual-memory promote) is built
-  default-off. Current wall: commit the GR engine context and make the engine
-  execute the submitted compute block. Next routes: the static root-cause of
-  the compute-object construct, forwarding the guest's own captured GR
-  operations, or the new candidate. All parameters remain default off; the
-  software path is unchanged with them off.
+  or the promote shape. Since then three more supervised cycles (modes 20, 21
+  and 22, module `1c69c03b…`) closed out the client-promote shape space on the
+  default external VAS: every kernel-managed-channel variant - single MAIN,
+  VA-only, bare VA+size, `hVirtMemory`, and `GPU_INITIALIZE_CTX` followed by
+  `hVirtMemory` - returns the same soft `NV_ERR_INVALID_STATE` (0x40) with a
+  clean release each time; adding the initialize step does not move it. The
+  five-element engine-class table decode and the Ghidra headless helper
+  scripts are recorded in the handoff (Addendum 25); the V5 path's commit
+  assert `0x52a8b04` is a secondary failure after an earlier non-zero commit
+  status. Current wall: commit the GR engine context and make the engine
+  execute the submitted compute block. Next routes: name the soft-0x40 check
+  in the commit helper, root-cause the V5 assert's first failure, or rehost
+  the promote flow in risc-v-gsp-rm-debugger. All parameters remain default
+  off; the software path is unchanged with them off. The guest-runnable
+  victory client (`tools/cuda-ab/victory_mail.cu`, host-oracle green) is ready
+  for the first green guest execution.
 - **Guest-submission relay and fault relay landed, default off (P6c
   C0/C1/C3, 2026-10-02 07:43-08:07).** With `gsp_phys_relay=1` the physical
   engine authors the guest CE copy and the release semaphore: the