diff --git a/tools/podium-repro/README.md b/tools/podium-repro/README.md
index ba2af1a..6f75fbe 100644
--- a/tools/podium-repro/README.md
+++ b/tools/podium-repro/README.md
@@ -223,6 +223,29 @@ exits, no exception. Then the cdb logs turned out to carry no
 weaker even than the earlier light-page-heap ones. Its only value is as one
 more sample of the crash failing to happen on its own.
 
+**2026-08-14 — THE RIG CAUGHT ONE, AND THE FIX HOLDS.** `loop.ps1`, four
+pods, full page heap. Launch 9 of the first batch trapped:
+
+    ExceptionAddress: rpl4opt!Quaternion::operator=
+      [inlined in Player::GoToVehicle+0xe]   reading a FREED block
+    free stack: operator delete <- VTV::`scalar deleting destructor'
+                                <- FryDeathRowTask::Execute
+
+`this` was a live remote `RPPlayer`. Cause: `Player::playerVehicle` is a bare
+pointer nothing ever cleared, and a replicant Player's whole performance is
+`GoToVehicle`, reading it every frame - so from the fry onward it read freed
+memory, normally mapped and full of garbage. Fixed in `f86b604` by clearing
+it in `Entity::CondemnToDeathRow`.
+
+Rate before the fix: 2 traps in 11 instrumented launches, about 1 in 5.
+After: **20 of 20 valid samples, no fault.** At the measured rate that is
+roughly a one-in-fifty coincidence, so the fix holds as well as twenty
+launches can say.
+
+A wasted batch in between is the reason `loop.ps1` now refreshes the pod
+exes: it trapped at the same address on the 09:33 binary while the fix sat
+in the 11:20 one. Check the `exe:` line before reading any result.
+
 **2026-08-14, FOUR pods, FULL page heap (`flags 0x3`), driven, podium ON:
 no crash. This is the first properly instrumented negative.** Everything the
 diagnosis points at ran and survived: `WinnersCircle: 4 placed on 8 spots`,