STATE-CURRENT: D0 lock verified 3/3 supervised claim/release cycles; real GSP boot is next

1 files changed, 23 insertions, 17 deletions

diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md
index d57a7f4..3a3fd3d 100644
--- a/STATE-CURRENT.md
+++ b/STATE-CURRENT.md
@@ -94,10 +94,13 @@ chain succeeds.
   firmware staging and the boot layout, but unbinding the distribution driver
   can power-gate this laptop's dGPU and hard-freeze the host (two occurrences,
   now root-caused), so that path is disabled behind a two-parameter hazard
-  gate; a power-domain lock that keeps the board in D0 across the handoff is
-  now implemented behind that gate and awaits a supervised claim/release test.
-  Meanwhile the emulation/VM CUDA verification cycles resume -
-  they never touch the driver binding.
+  gate. A power-domain lock that keeps the board in D0 across the handoff is
+  implemented and **verified across three supervised claim/release cycles on
+  2026-10-01** (zero power-domain cycles, zero failed resumes, distribution
+  driver rebound cleanly each time, host healthy); the verified launch
+  harness holds the GPU and root port in D0 before the distribution driver is
+  stopped, and the root-port hold is the load-bearing invariant. The real GSP
+  boot is the next stage.
 - Observability: a size-keyed copy watch, a VRAM shadow dump/search, and an
   operation log are now module parameters, and the test's output survives
   guest-agent stalls via the serial console.
@@ -107,9 +110,10 @@ chain succeeds.
   crashed the guest kernel (a NULL callback in interrupt context) before any
   emulation channel existed - guest-side and untriaged; treat no-watcher runs
   as a known risk. The host stays stable throughout.
-- Execution backend (chosen, then hazard-gated): the module owns the physical
-  GPU and will run its real GSP firmware as the resource-manager server, so
-  real work executes with an unmodified host driver and no host daemon; see
+- Execution backend (chosen; ownership hazard mitigated and verified): the
+  module owns the physical GPU and will run its real GSP firmware as the
+  resource-manager server, so real work executes with an unmodified host
+  driver and no host daemon; see
   [`docs/03-architecture/08-physical-gpu-integration.md`](docs/03-architecture/08-physical-gpu-integration.md).
   The ownership path was verified live (release the distribution driver from
   the device, bind the module, map the BARs, sample the falcon state, then
@@ -117,10 +121,9 @@ chain succeeds.
   matching GSP image is fetched and validated (ELF64 RISC-V, loadable
   image/version/signature sections identified) and the protected-region
   video-memory/boot layout is computed and logged - all without device writes.
-  The real GSP boot is **on hold**: the unbind/rebind that device ownership
-  requires can power-gate this laptop's dGPU and hard-freeze the host, so the
-  backend is being redesigned to keep the distribution driver bound
-  (proxy/callback options) before any further boot work.
+  The unbind/rebind hazard is mitigated by the D0 power-domain lock, verified
+  over three supervised cycles; the next stage is the real GSP boot (secure
+  verification, booter, RISC-V start, resource-manager init).
 - Host stability: the host hang class observed on 2026-09-28 (kernel stack
   overflow in a channel snapshot path) is fixed and frame-audited; repeated
   VM load/attach/teardown cycles run without panics or pstore records. A
@@ -133,13 +136,16 @@ chain succeeds.
   about a minute later (no crash record; journal stops, pstore empty; both
   occurrences followed an unbind/rebind, and prior log history has no other
   instance). The claim path refuses to run unless both `gsp_phys_gpu=1` and
-  `gsp_phys_hazard_ack=1` are passed, and the designed power-domain lock (hold
-  the GPU and its board functions plus the root port in D0 across the handoff,
+  `gsp_phys_hazard_ack=1` are passed, and the power-domain lock (hold the GPU
+  and its board functions plus the root port in D0 across the handoff,
   aborting and holding the locks on any power-loss signature) is now
-  **implemented** behind that gate; it must still pass a supervised
-  claim/release test before any further backend boot work, and it must not run
-  unattended. Normal module/VM work does not touch the driver binding and is
-  unaffected. See
+  **implemented and verified across three supervised claim/release cycles**
+  (2026-10-01: zero power-domain cycles, zero failed resumes, clean rebind,
+  host healthy). The verified launch harness holds the GPU and root port in
+  D0 before the distribution driver is stopped; the root-port hold is the
+  load-bearing invariant. The path must still not run unattended and every
+  cycle is supervised. Normal module/VM work does not touch the driver
+  binding and is unaffected. See
   [`docs/03-architecture/08-physical-gpu-integration.md`](docs/03-architecture/08-physical-gpu-integration.md).
 
 ## Initialization, work and teardown path