STATE-CURRENT: cdt2 baseline re-verified; second freeze class mechanism and power-domain mitigation recorded

1 files changed, 18 insertions, 11 deletions

diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md
index b5db841..1cd6620 100644
--- a/STATE-CURRENT.md
+++ b/STATE-CURRENT.md
@@ -43,6 +43,10 @@ chain succeeds.
 
 ## Right now (frontier)
 
+- **Driver-API baseline re-verified on the current build**: the smoke test
+  passes end-to-end (`ALL OK`, payload 64/64) with real releases
+  (`faked=0`, `miss=0`, `stale=0`), confirming the recent pump/parser and
+  rewind changes did not regress the baseline.
 - **The full CUDA driver-API smoke test passes with correct data**: the client
   completes `cuCtxCreate -> cuMemAlloc -> cuMemcpyHtoD -> cuMemcpyDtoH ->
   cuMemFree -> cuCtxDestroy` and prints `ALL OK`, with the 64-byte payload
@@ -119,17 +123,20 @@ chain succeeds.
 - 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
-  second, distinct freeze class was root-caused on 2026-09-30: unbinding the
-  distribution driver (as the physical-GPU claim path does) lets the dGPU
-  board power-gate, and the re-bind intermittently leaves the GPU
-  unresponsive (`not ready ... after resume`) with the host hard-freezing
-  within about a minute (no crash record either time; journal stops, pstore
-  empty; both occurrences followed an unbind/rebind, and the full prior log
-  history has no other instance). The claim path therefore refuses to run
-  unless both `gsp_phys_gpu=1` and `gsp_phys_hazard_ack=1` are passed;
-  normal module/VM work does not touch the driver binding and is unaffected.
-  Ownership-changing bring-up must not continue until the execution backend
-  is redesigned to keep the distribution driver bound (host-RM proxy); see
+  second, distinct freeze class was root-caused on 2026-09-30: the dGPU
+  board's power rail is gated by an ACPI power resource behind its root
+  port, released through an embedded-controller command. Unbinding the
+  distribution driver (as the physical-GPU claim path does) lets the device
+  runtime-suspend, the rail is cut, and the re-bind intermittently fails to
+  power it back (`not ready ... after resume`), with the host hard-freezing
+  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 it must not run again until the
+  designed power-domain lock (hold the GPU and its board functions plus the
+  root port in D0 across the handoff, aborting on any power-loss signature)
+  is implemented and verified under supervision; 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