acdream/docs/research/2026-08-06-ad10-review-retail.md

# 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 `<para>` block sits at document top level from line 40, and a
second, unmatched `</summary>` 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 `<para>` inside the first `</summary>` 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).**