diff --git a/docs/ISSUES.md b/docs/ISSUES.md
index a1c449cf..ac6dd62b 100644
--- a/docs/ISSUES.md
+++ b/docs/ISSUES.md
@@ -24,6 +24,79 @@ What does NOT go here:
 - Every session: scan OPEN issues at start; promote/close anything we touched during the session before ending.
 - Promoting to a Phase: mark as `DONE (promoted to Phase X)` + commit SHA where the Phase entry landed.
 
+## #32 UPDATE 2026-08-07 — the set_contact_plane split is NECESSARY BUT NOT SUFFICIENT
+
+**The fix at `332045c7` did not change the live behaviour.** Re-run at Rithwic
+with the same probe produced a **byte-identical** capture: six
+`branch2/steep-cliffslide` events, `curN = lastN = (-0.954,0.000,0.301)`,
+`angle=0.0000`, `apply=False`, outcome `degenerate-cross/last-known`. The user
+still falls straight through the edge.
+
+**The commit is not wrong and is not reverted.** It genuinely restores retail's
+setter split (`COLLISIONINFO::set_contact_plane` @0x00509d80 writes the contact
+group only) and is sabotage-verified by `Issue32LastKnownContactPlaneTests`.
+It closes one writer. It is simply not the writer that matters here, and the
+research's Section 7 — which enumerated `SetContactPlane`'s 13 call sites —
+did not consider the one below.
+
+### What the caller-attributed capture shows
+
+`ACDREAM_PROBE_CONTACT_PLANE=1`, writers of `LastKnownContactPlaneValid`:
+
+| writes | caller |
+|---|---|
+| 26,358 | `PhysicsEngine.ResolveWithTransition` |
+| 278 | `PhysicsEngine.ResolveWithTransition` (second site) |
+| 30 | `Transition.ValidateWalkable` |
+| 3 | `FlatBspQuery.StepSphereDown` |
+
+The only last-known writes in that method are `PhysicsEngine.cs:2041-2044` —
+**`check_contact`'s FAILURE branch**, which seeds
+`ci.LastKnownContactPlane = body.ContactPlane`.
+
+### The loop this suggests — NOT YET PROVEN
+
+`PhysicsEngine.cs:2041-2044` seeds `ci.LastKnown` FROM `body.ContactPlane` at
+the start of a resolve, and `PhysicsEngine.cs:2168-2174` writes
+`body.ContactPlane` FROM `ci.LastKnownContactPlane` at the end of one. The
+plane therefore round-trips through the body between frames. If the steep face
+enters that loop once, it persists — and `SetContactPlane` no longer needs to
+latch anything for `cliff_slide` to see `lastN == curN`.
+
+**That is a hypothesis built on a line-number mapping, and the line numbers are
+from an optimised Release build where inlining makes attribution approximate.
+Do not act on it without confirming which of the two branches actually runs.**
+
+### ⚠ BLOCKER — resolve this BEFORE trusting any probe result in this area
+
+An **unconditional** one-shot `Console.WriteLine` placed at the top of
+`ResolveWithTransition` (`PhysicsDiagnostics.AnnounceStepHeightProbeOnce`)
+printed **zero times** in a run where that same method is attributed 26,358
+plane writes. Both cannot be true.
+
+Candidate explanations, none verified:
+1. The running process loaded `AcDream.Core.dll` from somewhere other than
+   `src/AcDream.App/bin/Release/net10.0/` — the byte check confirmed the probe
+   string is in THAT copy, not that the process loaded it.
+2. The caller attribution's method name is wrong (it comes from a stack walk,
+   which an optimised build can misattribute after inlining), so the 26,358
+   writes are from a different method entirely.
+3. Something resets the one-shot flag, or the write goes to a stream not
+   captured by `Tee-Object`.
+
+**Settle this with a check that cannot be explained away** — e.g. print
+`typeof(PhysicsEngine).Assembly.Location` at startup — before doing any more
+work on #32 or #338. Three conclusions were drawn from probe silence in this
+session and all three were premature; the instrument must be trusted before its
+output is.
+
+### #338 is blocked on the same thing
+
+`[step-h]` has now been silent through two placements. Same blocker, same
+resolution.
+
+---
+
 ## #339 — Stuck in portal space: the destination reveal generation never becomes ready
 
 **Status:** OPEN — observed live 2026-08-07, evidence captured. **Not chased**;