STATE-CURRENT: reliability wave 2 (m163-m170) snapshot - stalls closed (live-session flush guard, no-capture hold, fail-closed arg spans, pool fresh-pin applies), greens verified across boots; remaining vidmem H2D data class characterized

1 files changed, 18 insertions, 0 deletions

diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md
index 15e23f3..af7165d 100644
--- a/STATE-CURRENT.md
+++ b/STATE-CURRENT.md
@@ -253,6 +253,24 @@ isolation, performance, portability).
        contamination demonstrated live) and needs the per-guest ownership rework
        (owner-tagged pin/map/pending lookups) before any dual-CUDA claim. No reboot;
        host GPU green; both guests left running.
+      **Update 2026-10-16 ~22:35 (reliability wave 2, m163-m170; seven cycles, no host reboots):**
+       the stall classes that made clients freeze at DEVICE are largely closed. Fixed and
+       verified across boots r172/r174/r175: the session flush can no longer wipe a live
+       session (a deferred flush executed with the client's channels valid, dropped its
+       queued launch release, and froze it in the tracker wait); GR entries whose decode
+       sees QMD words but builds no launch candidate are held and re-captured instead of
+       consumed silently; a failed device-destination copy holds its entry instead of
+       silently dropping the data; pool releases apply at fresh-pin time instead of
+       registration+5 s; the timeout ladder fails fast when the engine is wedged; argument
+       spans whose first page resolves nothing hold the launch (bounded) instead of
+       forwarding stale operands; device-destination copies answered only by a page-table
+       walk wait (bounded 3 s) for a pin. `victory_mail`, `victory_matmul` and `smiley`
+       are green on every boot of the wave, including the user's exact repro and mail as
+       the eighth client of a used boot. streams2/memset2d/saxpy no longer wedge - they
+       now fail fast (~35-60 s) on the remaining data class: an H2D into a device buffer
+       that does not land where the launch's data fill later reads the operand (the
+       vidmem write path vs the fill's read path divergence; analysis and the ranked
+       ledger fix are in the private handoff, cont. 23).
       **Update 2026-10-16 ~18:40 (reliability wave m160-m162 + harness fixes; verified battery, no reboots):**
        five cycles (r163-r167) landed and verified the bounds of the earlier "STATUS FAIL /
        freeze" repro. Fixed and live-verified across boots: `victory_mail` and