docs: #32's setter split is necessary but NOT sufficient — and the instrument is not trustworthy yet

The 332045c7 fix produced a byte-identical live capture at Rithwic: same
six events, same curN == lastN, same apply=False. The user still falls
through. The commit is not wrong and is not reverted — it restores
retail's setter split and is sabotage-verified — but it closes a writer
that is not the operative one here.

Caller-attributed capture puts 26,358 last-known writes in
PhysicsEngine.ResolveWithTransition, whose only such writes are
check_contact's FAILURE branch seeding from body.ContactPlane. Recorded
with the loop that suggests (2041-2044 seeds ci from body; 2168-2174
writes body from ci) explicitly marked NOT PROVEN, because it rests on
line-number mapping from an optimised build where inlining makes
attribution approximate.

Filed with a BLOCKER at the top: an unconditional one-shot WriteLine at
the head of that same method printed zero times. Both facts cannot hold.
Three conclusions were drawn from probe silence this session and all
three were premature, so the entry says to settle assembly identity with
a check that cannot be explained away before any further work on #32 or
#338 — rather than let a fourth inference compound the first three.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

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**;