diff --git a/docs/ISSUES.md b/docs/ISSUES.md
index 64bfab13..fa1654a8 100644
--- a/docs/ISSUES.md
+++ b/docs/ISSUES.md
@@ -13089,3 +13089,47 @@ meshes; scrolling cloud layers kept `GL_REPEAT`. The 5 dome walls were
 sampling opposite-edge pixels via UV wrap + LINEAR filtering, producing
 visible seam lines that formed a cube outline across the view.
 -->
+
+## #316 — The player arm's LANDING TRANSITION block never publishes the collision shadow
+
+**Status:** OPEN
+**Severity:** UNKNOWN pending one measurement (see "The open question") — either
+a ~33 ms shadow lag (cosmetic, invisible in practice) or the #184
+invisible-but-solid class (real). Do not act on it before measuring.
+**Filed:** 2026-08-04
+**Component:** physics / collision / remote presentation
+
+**Found by** the OnPosition-collapse contract scoping
+(`docs/research/2026-08-04-onposition-collapse-contract.md`), which neither
+C4 route 4b-3 review round caught. Confirmed independently by reading the
+block.
+
+**Description:** `LiveEntityNetworkUpdateController.OnPosition`'s player-guid
+LANDING TRANSITION block (the `!rmState.Body.InContact` hard-snap) does all of:
+`Interp.Clear()`, the body position/orientation snap,
+`TryArmConstraintAfterOperation`, the render-entity sync
+(`entity.SetPosition` / `ParentCellId` / `Rotation`),
+`EnsureRemoteMotionBindings`, and the landing probe — then returns. It never
+calls `LiveEntityShadowPublisher.TryPublishRemote`. The three publish sites in
+the file all sit outside this block, and the NPC-guid copy's equivalent
+scenario DOES publish through its arm tail.
+
+So a landing player-remote's body and render entity move to the authoritative
+landing pose while its collision shadow stays at the pre-snap position.
+
+This also contradicts the file's own #184 Slice 2b comments, which assert
+"player shadows follow the resolved body exactly like NPCs". Those comments
+are the stale-comment class the campaign has hit six slices running.
+
+**The open question (measure before fixing):** the per-tick remote physics
+commit syncs shadows on translation/orientation/cell change, so this may
+self-heal on the next tick (~33 ms) rather than persisting. Whether it does
+decides whether this is cosmetic or the #184 class. Resolve by landing a
+remote player observer and sampling the shadow entry position against the body
+across the landing frame and the following tick — `ACDREAM_PROBE_REMOTE_LANDING`
+already instruments the packet side of exactly this edge.
+
+**Why it is NOT fixed in the collapse:** the collapse is behaviour-preserving
+by contract; adding a publish would be a behaviour change smuggled into a
+refactor, and its severity is unmeasured. Split-on-discovery: own commit, with
+a dual-guid test, after the measurement.