# AD-10 retirement — retail-conformance review **Verdict: PASS**, with one MEDIUM documentation defect that must be corrected before the register row is trusted (AD-65's quantification), and three LOW items. - **Reviewed:** `ef976c6d..2223ed17` on `claude/acdream-physics-divergence-5aa784` in worktree `.claude/worktrees/peaceful-visvesvaraya-e0a196` (`fe6ee877`, `886333a2`, `fb454b74`, `2223ed17`). - **Lens:** retail conformance. Every retail claim below was re-derived from the PDB-paired binary, not from the contract, the commit messages, or the Binary Ninja pseudo-C. - **Binary:** `C:\Users\erikn\Downloads\acclient.exe`, `check_exe_pdb.py` → `=== MATCH ===`, linker UTC 2013-09-06T00:17:56, CodeView GUID `9e847e2f-777c-4bd9-886c-22256bb87f32`. Image base `0x00400000`. Disassembled with capstone x86-32 straight off the file, VA→file-offset through the section table; floats read from `.rdata` as raw bytes. - **Build/test:** all 44 `bin`/`obj` directories deleted, full `dotnet build AcDream.slnx -c Release` → **0 errors**; full `dotnet test --no-build` → **0 failed**. Staleness disproved positively: `SampleTerrainNormal` is **absent** from the freshly built `AcDream.Core.dll` byte image (and `RuntimeRemoteSlopeProjectionTests` is present in the test image), so the runner is genuinely serving the deleted code. --- ## 1. Independent verification of the retail claims ### 1.1 Is `Transition.AdjustOffset` a faithful port of `CTransition::adjust_offset` @0x0050a370? **Yes — structurally exact, with exactly the two exceptions the change itself filed as AD-65 and AD-66. No third divergence found.** Function extent from the binary: `0x0050a370` (`sub esp,0x24`) to `0x0050a6c7` (`ret 8`), nops to `0x0050a6d0` where `CTransition::cliff_slide` begins. Symbol confirmed from `symbols.json`: `0x0050A370 CTransition::adjust_offset`, mangled `?adjust_offset@CTransition@@IAE?AVVector3@AC1Legacy@@ABV23@@Z` (returns `Vector3`, takes `const Vector3&`). Field map recovered from the code: `this+0x2a8` = `sliding_normal_valid`, `this+0x2ac/0x2b0/0x2b4` = `sliding_normal.xyz`, `this+0x288` = `contact_plane_valid`, `esi = this+0x28c` = `contact_plane` (`N.x/N.y/N.z` at `+0/+4/+8`, `D` at `+0xc`), `this+0x2a4` = `contact_plane_is_water`, `this+0x29c` = `contact_plane_cell_id`, `this+0x34` → global sphere (`origin` `+0/+4/+8`, `radius` `+0xc`), `this+0x20` = sphere path. **All four x87 flag tests decoded** (the contract's count is right; here is each one, with the FPU condition-code reasoning — `fcom*` sets C0=1 for "ST0 < src", C3=1 for equal, C2=1 for unordered; `fnstsw ax` puts C0 at bit 0 of `ah`, C2 at bit 2, C3 at bit 6): | # | Address | Instruction | Meaning | acdream | |---|---|---|---|---| | 1 | `0050a3c4` | `test ah,1` after `fcomp [0x795344]` | C0 alone → `slidingAngle < 0` → `checkSlide = true`; else `sliding_normal_valid = 0` | `TransitionTypes.cs:5192-5199` ✅ | | 2 | `0050a502` | `test ah,0x41` / `0050a505 jne 0x50a515` | C0\|C3 → `collisionAngle <= 0` → subtract arm; fall through (`> 0`) → `call 0x509c50` | `:5246-5258` — **diverges, AD-65** | | 3 | `0050a5d3` | `test ah,5` + `jp 0x50a6a8` after `fcompp` | PF set ⇔ C0=C2 ⇔ (ordered) C0=0 ⇔ `dist >= radius - 0.0002` → skip push-out | `:5297` — **diverges in the threshold, AD-66** | | 4 | `0050a5ed` | `test ah,0x41` / `jne 0x50a6a4` | C0\|C3 → `radius <= abs(zDist)` → skip | `:5302` `radius > MathF.Abs(zDist)` ✅ | Everything else lines up instruction-for-instruction: - **No-contact-plane early return** (`0050a61c`): if `!checkSlide`, returns the offset untouched and jumps past the safety block; else `offset -= sliding_normal * slidingAngle` (`0050a624-0050a69e`) and still skips the safety block. acdream `:5202-5223` ✅ including the skip. - **Crease order.** `0050a412-0050a458` builds `cross(contact_plane.N, sliding_normal)` in that operand order (`[esp+0x14] = sn.z*cpn.y - sn.y*cpn.z` = `cross(cpn, sn).x`). acdream `:5228 Vector3.Cross(ci.ContactPlane.Normal, ci.SlidingNormal)` ✅. - **Degenerate-crease guard.** `0050a45c call 0x452460` = `AC1Legacy::Vector3::normalize_check_small`; disassembled at `0x00452460` it computes `len = sqrt(x²+y²+z²)`, compares against `[0x79b6ac]` = **0.0002f** (raw `17b75139`), returns 1 (and leaves the vector alone) when `len <` that, otherwise normalizes and returns 0. Retail then zeroes the offset on return-1. acdream `:5233-5243` computes the length, compares `slideLen < PhysicsGlobals.EPSILON` (= 0.0002), zeroes on true, else divides by the length and dots — algebraically identical, same threshold, same constant ✅. - **Safety block gating** `contact_plane_is_water == 0 && contact_plane_cell_id != 0` (`0050a569`, `0050a577`) ✅ `:5285`. Retail additionally converts through `LandDefs::get_block_offset` (`0x0043E630`, called at `0050a592`) because its contact plane is cell-local; acdream's sphere is already global — a representational difference, not a behavioural one. - **Push-out vector** `(0, 0, zDist)` and `SPHEREPATH::add_offset_to_check_pos` (`0x00509D10`, called at `0050a612` with `ecx = this+0x20`) ✅ `:5304`. Cross-check: **ACE agrees with retail on both divergent points** (`references/ACE/Source/ACE.Server/Physics/Transition.cs:60-88` calls `ContactPlane.SnapToPlane(ref offset)` on the `else` arm and uses the bare `globSphere.Radius` in both the trigger and the numerator). So acdream is the outlier against both oracles, which is what AD-65/AD-66 now record. ### 1.2 Does retail project against `collision_info.contact_plane`, and who produces it? **Yes, and the producer set is broader than claimed — which strengthens rather than weakens the argument.** `adjust_offset` reads `this->collision_info.contact_plane` at `edi+0x28c` gated on `contact_plane_valid` at `edi+0x288`. It is called **per sub-step** from inside the step loop of `CTransition::find_transitional_position` (`0x0050BDF0`, call at `0050bf66`, immediately followed by the `WalkInterp = (i+1)/numSteps` computation at `0050bfc2-0050bfe9` that identifies the loop body); the only other caller is `CTransition::find_placement_pos` (`0x0050BA50`, call at `0050bcfd`). Two call sites total, byte-scanned across the whole `.text` for `E8` rel32 targets. Byte-scanning `.text` for calls to `COLLISIONINFO::set_contact_plane` (`0x00509D80`) gives **nine** producers: ``` 0050ab37 CTransition::validate_transition +0xc7 0050acca CTransition::validate_transition +0x25a 0050d1c7 OBJECTINFO::validate_walkable +0x1b7 0050d2e1 OBJECTINFO::validate_walkable +0x2d1 00536ecf CSphere::step_sphere_down +0x1af 00537db1 CSphere::intersects_sphere +0x331 0053a5ee BSPTREE::find_collisions +0x1ae 0053aae2 CCylSphere::step_sphere_down +0x132 0053b6b9 CCylSphere::intersects_sphere +0x279 ``` `BSPTREE::find_collisions` and both `step_sphere_down` variants are on the list, so the claim that retail's contact plane natively carries building and EnvCell geometry — the gap a terrain-only XY sample structurally cannot cover — **is confirmed**. Two nits, neither material: `BSPTREE::step_sphere_down` (`0x0053A210`) is *not* itself a setter (it reaches the plane through the `CSphere`/`CCylSphere` pair), and the claim omits `intersects_sphere` ×2 and the `validate_*` pair. Corroborating the other half of the argument — that retail has **no** pre-sweep projection: `CPhysicsObj::UpdatePositionInternal` (`0x00512C30`, pc:280817) is `CPartArray::Update` → root-frame scale gated on `transient_state & 2` (`0x00512CA1`; `× m_scale` when set, `× 0` when clear) → `PositionManager::adjust_offset` → `Frame::combine` → `UpdatePhysicsInternal` → `process_hooks`. No plane, no normal, no dot product anywhere before the sweep. ✅ ### 1.3 Constants Read as raw bytes from `.rdata` at the stated VAs: | VA | Bytes | Value | |---|---|---| | `0x00795344` | `00000000` | `0.0f` ✅ | | `0x007c6878` | `17b75139` | `0.00019999999494757503f` ✅ | | `0x0079b6ac` | `17b75139` | same 0.0002f (the `normalize_check_small` threshold) | | `0x007928c0` | `000000000000f03f` | `1.0` (double, `snap_to_plane`'s reciprocal numerator) | ### 1.4 AD-65 — the `snap_to_plane` substitution **Disassembly claim: CONFIRMED exactly. Trigonometric formula: CONFIRMED. Percentages: WRONG — see finding F1.** `0050a4fa fcomp [0x795344]` / `0050a502 test ah,0x41` / `0050a505 jne 0x50a515` are byte-for-byte as the row states, and the FPU reasoning is right: `jne` takes the SUBTRACT arm at `0x50a515` (which is literally `result -= N * collisionAngle`, spelled out at `0050a515-0050a565`) when `cAngle <= 0`, and falls through to `call 0x509c50` when `cAngle > 0`. `0x00509C50` is `Plane::snap_to_plane` per `symbols.json`, and disassembling it gives, after an early return when `|N.z| <= 0.0002`: ``` v.z = -(v.x*N.x + v.y*N.y) / N.z ; v.x and v.y are never written ``` (the `+D` and `-D` terms at `0050a58f`/`0050c996` cancel exactly; ACE's `PlaneExtensions.SnapToPlane` writes the same cancelling pair). acdream's `else` arm at `TransitionTypes.cs:5252-5258` is instead `result -= N * collisionAngle`, identical to the `if` arm — the row's core claim, confirmed. Geometry, re-derived independently. Slope descending along +X at angle θ has outward normal `N = (sinθ, 0, cosθ)`. For a horizontal step `v = (d, 0, 0)` downhill, `v·N = d·sinθ > 0` → the `snap_to_plane` arm: - retail: `(d, 0, -d·tanθ)` — **XY preserved at `d`**, along-plane speed `d/cosθ`; - acdream: `(d·cos²θ, 0, -d·sinθ·cosθ)` — **XY = `d·cos²θ`**, along-plane speed `d·cosθ`. So the XY ratio is `cos²θ`. The row's *formula* is right. ### 1.5 AD-66 — the safety push-out threshold **CONFIRMED, all four operand loads, verbatim.** ``` 0050a5c4 d9410c fld dword ptr [ecx+0xc] ; bare radius 0050a5c7 d82578687c00 fsub dword ptr [0x7c6878] ; - 0.0002f 0050a5cd d9c1 fld st(1) ; dist 0050a5cf ded9 fcompp ; dist vs radius - eps ... 0050a5dc d8690c fsubr dword ptr [ecx+0xc] ; radius - dist (bare radius again) 0050a5df d87608 fdiv dword ptr [esi+8] ; / contact_plane.N.z ``` Neither site multiplies by `N.z`. acdream substitutes `naturalRestingDist = radius * ci.ContactPlane.Normal.Z` in **both** places (`TransitionTypes.cs:5295` and `:5301`), exactly as the row says, and the row is right that ACE has retail's form too — so "ACE and the published pseudocode have the original threshold" in the code comment does understate it. Filing an argued-but-unrecorded deviation is correct register hygiene. ### 1.6 Address / anchor precision audit Every cited address re-checked as the construct claimed (this is the class of error that produced AP-150's mis-cite): | Citation | Verified | |---|---| | `CTransition::adjust_offset` `0x0050a370` | ✅ symbol + `ret 8` at `0x0050a6c7` | | `Plane::snap_to_plane` `0x00509c50` | ✅ symbol; body is the z-only solve | | `0050a4fa` / `0050a502` / `0050a505` | ✅ exact instructions as quoted | | `0050a5c4` / `0050a5c7` / `0050a5dc` / `0050a5df` | ✅ exact instructions as quoted | | `0x795344 = 0.0f`, `0x7c6878 = 0.0002f` | ✅ raw bytes as quoted | | `CTransition::find_transitional_position` `0x0050bdf0` | ✅ symbol; per-step call at `0050bf66` | | pc:272271–272393 | ✅ 272271 is the `adjust_offset` signature line, 272393 the closing `}` — **exact** | | pc:271852 (`snap_to_plane`) | ✅ exact signature line | | old anchor pc:272296–272346 "truncated" | ✅ 272296 = `float __return_1;` (after the sliding-normal gate closes at 272292); 272346 = `if (contact_plane_is_water == 0)` (the safety block's first line). Both truncations real. | AD-65's methodological claim — that Binary Ninja "cannot be read for branch direction" — is accurate and correctly narrow. BN *does* render the `snap_to_plane` call plainly (pc:272322) and gets the arm order structurally right; what it cannot express is which FPU condition bits `test ah,0x41` selects, which it emits as `(*(uint8_t*)((char*)eax_4)[1] & 0x41) != 0`. The disassembly was necessary and the row does not overclaim. --- ## 2. Is the deletion itself retail-faithful? Yes, and more strongly than the commit argues. - The sweep genuinely runs for remotes: `RuntimeRemotePhysicsUpdater.cs:414` calls `_physics.Engine.ResolveWithTransition(preIntegratePos, postIntegratePos, …, body: rm.Body, …)` and `:457` assigns `rm.Body.Position = resolveResult.Position` unconditionally, so the sweep is authoritative over the composed root motion. The old row's justification ("remote bodies don't run a full local transition sweep") was indeed false, and the retirement row says so. - `PhysicsEngine.SampleTerrainWalkable` (`PhysicsEngine.cs:1023`) is a pure `(worldX, worldY)` landblock scan — Z-blind, cell-blind, statics-blind. The "wrong surface on a bridge/roof/dungeon ramp" claim is structural, not rhetorical. - Retail has no pre-sweep projection (§1.2). Deleting one is the retail direction regardless of what the measurement had shown. - The composition-idempotence argument holds: after `v -= N·(v·N)`, `dot(v, N) == 0`, so a second projection against the same plane is a no-op — which is why the trajectory came out bit-identical, and why the deletion cannot regress the same-plane (terrain) case. Residue check: no production caller of `RemoteMotionCombiner.ComputeOffset` remains (tests only), `SampleTerrainNormal` survives only in comments, and the parameter removal makes a one-site regression a compile error as claimed. --- ## 3. Findings ### F1 — MEDIUM. AD-65's percentages are wrong by ~2×, and contradict its own formula and the project's own measurement `docs/architecture/retail-divergence-register.md`, row AD-65: > acdream therefore descends slopes SLOWER than retail by cos^2(theta) in XY: > **13% slow at 30 degrees, 29% at 45 degrees**. `cos²(30°) = 0.750` → **25% slow**. `cos²(45°) = 0.500` → **50% slow**. The quoted figures are `1 − cos θ` (13.4% and 29.3%), not `1 − cos²θ`; the row states the correct factor and then quantifies a different one. This is not a matter of interpretation — the same push measured it. **#331** (`docs/ISSUES.md`, added in `2223ed17`) records a probe on the gradient-0.6 ramp (θ = 30.96°): `the XY advance is 0.0735 m for a 0.1 m request`. That is `cos²(30.96°) = 0.7353`, i.e. **26.5% slow** — a direct empirical refutation of "13% at 30 degrees", sitting in a neighbouring file in the same commit series. Consequence: AD-65 is filed as a **lead for #269**, and the number is exactly what a future reader will weigh when deciding whether the lead is worth chasing. Halving the magnitude makes a 50%-at-45° downhill speed loss look like a rounding-error feel issue. **Fix the two percentages to 25% and 50% before this row is used for anything.** - Retail: `CTransition::adjust_offset` `0x0050a370`, arm select at `0050a505`; `Plane::snap_to_plane` `0x00509c50`. - acdream: `src/AcDream.Core/Physics/TransitionTypes.cs:5252-5258`. - Observable in game: a player or remote running downhill on a 45° face covers half the ground per second that retail does (25% less at 30°); on the same input the body's along-plane speed is `d·cosθ` where retail's is `d/cosθ`. Uphill is correct. ### F2 — MEDIUM. "Verbatim / faithful port" is asserted about `Transition.AdjustOffset` in five places, and is false as of the very next commit The change repeatedly certifies the port it is standing on: - `src/AcDream.Runtime/Physics/RuntimeRemotePhysicsUpdater.cs:276` and `:321` — "**ported verbatim** in `Transition.AdjustOffset`"; - `src/AcDream.Core/Physics/RemoteMotionCombiner.cs:46` — "acdream ports that **verbatim**"; - `tests/AcDream.Runtime.Tests/Physics/RuntimeRemoteSlopeProjectionTests.cs:11` — "acdream ports that **faithfully**"; - the retired **AD-10** register row — "runs acdream's **verbatim port** of `CTransition::adjust_offset` once per sub-step"; - `fe6ee877`'s commit message — same phrase. One commit later, `fb454b74` files **two** divergences inside that exact function. The register now simultaneously asserts that `AdjustOffset` is a verbatim port and that it substitutes a different operation on one of its three arms and a different constant in its safety block. A future maintainer grepping "verbatim" for a trustworthy reference implementation will be misled, and the retired AD-10 row — the permanent record — is the worst place for it. Not a code defect; the deletion argument survives untouched (see F3 for why it in fact survives *because* of AD-65). But four comments and one register row should read "ported apart from AD-65 and AD-66" or cite them inline. ### F3 — LOW/MEDIUM. The "measured redundant" evidence is contingent on AD-65, and the register does not say so The bit-identical measurement is a consequence of the divergence filed the same day. acdream's away-plane arm is `v -= N·(v·N)` — *the same operation as the deleted pre-sweep projection* — so the composition is idempotent and deleting one changes nothing. If AD-65 is ever fixed, the away-plane arm becomes `snap_to_plane`, which **preserves** XY; a surviving pre-sweep projection would then have shrunk XY to `cos²θ` before `snap_to_plane` locked it in, and `snap_to_plane` (being a no-op on an already-on-plane vector) would have had no way to recover it. So the deletion is not merely safe — it is a **prerequisite** for AD-65's eventual fix, and the ordering (delete first, then fix AD-65) is the right one. That is a point in the change's favour, and it is missing from the record. The retired row reads "measured redundant" flat, which invites a future reader to conclude the pre-sweep layer was always a no-op on principle. Recommend one sentence in AD-65 and/or the retired AD-10 row noting the interaction. Related, minor: the surviving measurement is **downhill-only**, because #331 made the uphill counterpart vacuous. The commit message and #331 are both candid about this; the register row is not, and simply says "30 ticks down a 31-degree ramp" — which is accurate but reads as a choice rather than as a constraint. No action required beyond awareness. ### F4 — LOW. Malformed XML doc on `ComposeOffset` will hide the AD-10 note from tooling `src/AcDream.Core/Physics/RemoteMotionCombiner.cs:34-53`: the summary closes at line 38, the AD-10 `` block sits at document top level from line 40, and a second, unmatched `` appears at line 52. The project sets no `GenerateDocumentationFile`, so the compiler is silent — but IDE tooltips and any generated docs will show only the first paragraph and drop the retirement note, which is precisely the note a future maintainer of this method needs. Move the `` inside the first `` and delete the second. ### F5 — LOW. AD-65 and AD-66 cite files without lines Both new rows name `src/AcDream.Core/Physics/TransitionTypes.cs` with a prose description of the block. Adjacent rows (AD-5, AD-12, AD-13, AD-62, AD-64) give `file:line`. The exact anchors are `:5252-5258` (AD-65's `else` arm) and `:5285-5310` (AD-66's safety block). In a 5,000-line file this matters. ### F6 — informational. A foreign untracked file appeared in the worktree mid-review and must not be committed `tests/AcDream.Runtime.Tests/Physics/ZzReviewTrajectoryDump.cs` (self-described "TEMPORARY reviewer probe (2026-08-06 AD-10 architecture review). Delete.", 13 test attributes) was **not** present at the start of this review and appeared at 09:49 during it — a concurrent review session writing into the same worktree. It was compiled into the Release build and inflated the raw suite count by 12. It is not part of this change and must be deleted before merge. --- ## 4. Bookkeeping audit **AD-10's retirement is earned by the code, not asserted.** Positive evidence: `SampleTerrainNormal` is absent from the freshly built `AcDream.Core.dll` image; the `terrainNormal` parameter is gone from both `ComposeOffset` and `ComputeOffset`; both `RuntimeRemotePhysicsUpdater` fork branches are cleared; the two Core tests are deleted; nothing but comments references the removed API. The row follows house style — `~~AD-10~~`, bold **RETIRED 2026-08-06 by deletion**, past tense, evidence inline, `—` in the justification/risk columns, retail anchor retained and corrected — matching the ~~AD-6~~ / ~~AD-11~~ precedent. Removing the parameter rather than defaulting it to `null` is the right call and does make a one-site regression a compile error. Three stale claims in the old row are recorded rather than dropped (the false "remotes don't run the sweep" justification, the "interpolation-active" mis-description of `if (!interpolationOverwrote`, and the roof clause dead since Bug B gated on `OnWalkable`). All three check out against the code. **AD-65 and AD-66 are honestly scoped.** AD-65 explicitly says "Not justified — this is an unexamined substitution, not a decision", and explains why it is filed rather than fixed (it changes local-player feel and needs its own visual gate; folding it into a remote-movement change would put a local-player regression behind the wrong acceptance test). That reasoning is correct. AD-66 is scrupulous in the other direction: "Filed to make the deviation auditable, not to assert it is wrong", and it names the failure mode in both directions. Neither row claims more than the disassembly supports — except for F1's numbers. **AD-65 is correctly recorded as a lead, not a diagnosis**, in bold, with "nothing here establishes causation" and "#269 still needs its live cdb A/B". It does **not** overreach into the exonerated area: it states explicitly that "#269's friction and jump chains are byte-exonerated and must not be re-audited; `adjust_offset` is a different function and is not covered by that do-not-retry". That is the correct boundary — `adjust_offset` was never part of the friction/jump byte-verification — and the row draws it itself rather than leaving a future reader to. **The #32 corrections are accurate.** Both edited paragraphs were checked against the code: - The "even a corrected `OnWalkable` would need a real contact-plane-derived slide" paragraph is correctly marked superseded with an inverted premise — remotes do run the sweep, and on a steep roof `bodyOnWalkableAtTickStart` was false anyway, so the deleted sample never ran on #32's geometry and the roof slide was already contact-plane driven. - The dependency paragraph is correctly struck and replaced with "discharged rather than merely gated". - **The "does not fix #32, and does not partially fix it" claim holds**, and the commit message states it in exactly those words. #32's remote half closed at `204d0ae0`; nothing here touches the local-player edge-slide or the three recorded gaps. The genuine improvement claimed — a remote on a walkable *non-terrain* surface now gets its own committed contact plane rather than the plane of the ground far below — follows directly from `SampleTerrainWalkable` being XY-only, and is correctly described as a case #32 never covered rather than as progress on #32. **#331 and #332 are honest filings.** #331 records a probe result that *invalidated a test that had passed*, states severity UNKNOWN on purpose, lists five ruled-out hypotheses with the probe evidence for each, and names the single comparison that decides severity. #332 is scoped as an observation with an instantiation census rather than an inference, and records the reasoning trap (assembly placement ≠ reachability) that would otherwise have produced a vacuous headless gate. Both explicitly disclaim causation by AD-10, correctly. **Test-count reconciliation reproduces exactly.** Raw full-suite result on the clean Release build was 11,208 passed / 4 skipped / 0 failed; the foreign probe file (F6) contributes 12 executed tests (`--filter FullyQualifiedName!~ZzReviewTrajectoryDump` → Runtime 1,232 → 1,220). **11,208 − 12 = 11,196 passed / 4 skipped / 0 failed**, matching `886333a2`'s claim to the test. The `+3 Runtime / −2 Core` arithmetic is structurally verified too: `RuntimeRemoteSlopeProjectionTests` carries exactly three `[Fact]`s and the diff deletes exactly two Core tests. **Test honesty.** `RuntimeRemoteSlopeProjectionTests` states in its own doc comment that short-circuiting `Transition.AdjustOffset` leaves it GREEN, names the reason (`ValidateWalkable`'s push-out re-seats the sphere every sub-step), and forbids citing itself as a unit test of `adjust_offset`. The anti-vacuity guard (`dz < -1.0 m`) and the per-tick rather than start/end assertion are both the right shape. Expected values come from the fixture's own `TerrainSurface.SampleZ`, i.e. from geometry, not from a re-implementation of the projection formula — the weakness the two deleted Core tests had. --- ## 5. What was checked, so the PASS is auditable - PDB/EXE pairing (`check_exe_pdb.py` → MATCH) before any address work. - Full disassembly of `CTransition::adjust_offset` `0x0050a370-0x0050a6c7`, arm by arm, against `TransitionTypes.cs:5180-5322` line by line. - All four x87 condition-code tests decoded from `fnstsw`/`test ah` semantics. - `Plane::snap_to_plane` `0x00509c50` and `Vector3::normalize_check_small` `0x00452460` disassembled in full. - Four float/double constants read as raw bytes from `.rdata`. - Whole-`.text` `E8 rel32` scan for callers of `set_contact_plane` (9 producers) and of `adjust_offset` (2 call sites), symbolised against `symbols.json`. - `CPhysicsObj::UpdatePositionInternal` `0x00512C30` read end to end to confirm retail has no pre-sweep projection. - All pc: anchors checked by line number in `named-retail/acclient_2013_pseudo_c.txt`, including the old truncated one. - ACE cross-check (`Transition.cs`, `PlaneExtensions.cs`) on both divergences. - `RemoteMotionCombiner`, `RuntimeRemotePhysicsUpdater`, `PhysicsEngine.SampleTerrainWalkable`, `RemoteRampHarness`, `RuntimeRemoteSlopeProjectionTests` read in full. - Orphan/residue greps for `ComputeOffset`, `SampleTerrainNormal`, `terrainNormal`. - 44 `bin`/`obj` directories deleted; clean Release build (0 errors); full suite (0 failures); staleness disproved by byte-searching the built DLLs. **No third retail divergence was found in `AdjustOffset`, no mis-cited address was found, and no claim in the four commits was found to be unsupported by the binary — apart from AD-65's two percentage figures (F1).**