diff --git a/docs/plans/2026-08-06-collision-fidelity-campaign.md b/docs/plans/2026-08-06-collision-fidelity-campaign.md
index 0e15d580..1e2ebad0 100644
--- a/docs/plans/2026-08-06-collision-fidelity-campaign.md
+++ b/docs/plans/2026-08-06-collision-fidelity-campaign.md
@@ -128,21 +128,23 @@ the DATs.
 
 ---
 
-### S3 — Animated collision pose
+### S3 — Animated collision pose — CANCELLED 2026-08-07 (the slice was planned on a misreading)
 
-**Row:** AP-84. **Files:** `LiveEntityDefaultPoseResolver.cs`,
-`LiveEntityCollisionBuilder.cs`, `ShadowShapeBuilder.cs` (`partPoseOverride`).
+**Row:** AP-84 — which stays exactly as it is.
 
-Server entities with a MotionTableId register their BSP part shapes at the
-default style's first-cycle LowFrame pose and never update them; retail uses
-the live `CPhysicsPart` pose. A door's collision therefore stays where the shut
-door was.
+This plan's original S3 text claimed "a door's collision stays where the shut
+door was." **That scenario cannot occur, and AP-84's own row says why:** an
+open door is ETHEREAL (#150) and bypasses collision entirely, so the only
+pose a door ever collides in IS the registered default pose. The row's risk
+column already carries the honest residual — "an entity whose server-driven
+motion state materially moves a BSP-bearing part while NON-ethereal would
+collide at the stale default pose (no known case)" — with the revisit
+trigger written. The register was right; this plan's summary of it was
+wrong, which is the same reading failure the campaign's own governing
+lesson warns about, committed by the campaign plan itself.
 
-**Why not folded into S1:** different files, different subsystem (animation, not
-membership), and it needs a *visual* gate that S1 does not — you have to watch
-a door open and then walk through the doorway.
-
-**Gate:** live. Open a door, walk through, close it, walk into it.
+No fix, no gate, no door row in the morning sitting. AP-84 remains an
+active, deliberate approximation.
 
 ---