diff --git a/.claude/plans/x265-sprite-replay-probe-v1.md b/.claude/plans/x265-sprite-replay-probe-v1.md
index 00411972..425fb7fc 100644
--- a/.claude/plans/x265-sprite-replay-probe-v1.md
+++ b/.claude/plans/x265-sprite-replay-probe-v1.md
@@ -217,3 +217,52 @@ The arc's own sprite-replay motion coding (E-SPRITE-IPB-HELIX-1: one Signed360
 code per sprite per P-frame) is the thing being contextualized; the
 bitrate-comparison study (our object-level motion codes vs x265's per-block MV
 field on the SAME scene) is a NAMED follow-up, not done here.
+
+## Results (2026-07-18 — HEAD-TO-HEAD: our helix motion codes vs x265 MV field)
+
+The head-to-head the HEVC anchor set up: our object-level helix motion codes vs
+x265's per-block MV search, on the SAME φ-spiral scene. Reproducer:
+`lance-graph crates/helix/examples/hevc_headtohead.rs` (uses the REAL helix
+public API — `ResidueEncoder::encode_signed` / `Signed360` / azimuth-roundtrip
+decode — not a re-inline; 3 tests, clippy-clean).
+
+**Codex-P1 #740 correction:** the reproducer renders through helix's REAL
+`HemispherePoint::signed_lift(n, total, sign).cartesian()` (golden-RATIO azimuth,
+`r=√u`), NOT a local golden-angle approximation — so the scene IS the geometry
+`Signed360` encodes and this is a genuine helix-motion-code result. Numbers below
+are on that real-helix scene.
+
+| Lane | Bytes | bits/frame | PSNR | What the bytes are |
+|---|---|---|---|---|
+| A — x265 3.5 medium | 40,750 | 1358.3 | 61.27 dB | **TOTAL HEVC bitstream** — texture + residuals + modes + headers + MV, all syntax |
+| B — our helix `Signed360` | **432** (192 appearance + 240 motion) | 14.4 | **∞ (bit-exact)** | **TOTAL our-codec stream** — sprite appearance + object-motion (1× 6-byte code / sprite / P-frame) |
+
+**This is a TOTAL-stream vs TOTAL-stream comparison, NOT motion-vs-motion
+(codex-P2 #250).** Lane A's 43,115 B is the *entire* HEVC output — the 432 B does
+**not** replace only x265's MV field, it replaces x265's whole stream, which it
+can only do because it is model-based. Isolating x265's MV-only bits (via `--csv`
+per-frame syntax analysis) to test the "one code replaces the per-block MV field"
+thesis DIRECTLY is a named follow-up, not measured here.
+
+**Verdict: TAUTOLOGICAL-WIN / MODEL-MATCHED LOWER BOUND (KILL did not fire; NOT a
+general-codec win).** Lane B was handed the EXACT generative model of a
+self-generated φ-scene; the ∞ PSNR is the decoder re-running the same generator.
+Legitimately establishes the object-motion amortization's concrete bit-cost — one
+6-byte `Signed360` per sprite per P-frame = 240 B of motion for the whole
+240-frame GOP — as a TOTAL-stream lower bound on model-matched content. Does NOT
+beat x265 in general: (1) arbitrary non-φ-manifold motion needs stored residuals
+(PROBE-SPRITE-REPLAY's [H] gate); (2) x265's bytes encode actual pixels while
+ours encode model parameters — different things. Board: lance-graph
+`E-X265-HEADTOHEAD-1`.
+
+## Follow-up probe queued — PROBE-SPLAT-μ-HYDRATION-RHO (the spatial cousin)
+
+The operator's 3DGS↔blasgraph↔gridlake presumption, adjudicated by the
+convergence-architect (lance-graph `E-3DGS-MU-HYDRATION-1`): `splat3d::GaussianBatch`
+is ALREADY SoA, so the only net-new "gridlake" claim is **address-derived gaussian
+μ** (WORTH-EXPLORING on the φ-manifold — the SAME [H] gate as this head-to-head's
+temporal tautology). "EWA = blasgraph semiring" DROPPED (depth-sorted Porter-Duff
+*over* is non-commutative → axiom break). Named probe **PROBE-SPLAT-μ-HYDRATION-RHO**
+runs on a real trained Inria `.ply` (non-φ input via `splat3d::ply`): μ-hydration
+ratio + semiring-matches-EWA (commutative-⊕ vs sorted-over) + SoA-sweep throughput.
+PASS→[H] / KILL→DROP bands in the board entry.