fix(p1): membership already matches retail — the 0/11 was a cdb capture artifact

The P1 "doorway membership lags retail" premise is FALSIFIED. acdream's swept
ResolveWithTransition already matches retail's true per-frame curr_cell: the
production gate ProductionPath_IndoorCrossings reads 9/9 on the indoor 0170<->0171
crossings with NO code change, once fed an aligned retail golden.

Root cause of the false 0/11: CPhysicsObj::SetPositionInternal calls change_cell
(acclient_2013_pseudo_c.txt:283456) BEFORE set_frame writes m_position (:283458),
so the original golden (find-cell-list-capture.cdb, read at the change_cell BP)
paired each frame's NEW cell with the PREVIOUS frame's position — a one-frame skew.
Verified 3 ways: the decomp ordering; golden_picked[i] == geom(golden_position[i+1])
for all 22 rows; acdream's static pick == golden_picked[i-1] for all rows. Both
retail and acdream pick with center-only point_in_cell on global_sphere[0] (no XY
lead; cache_global_sphere @ pc:274196). curr_cell commits via validate_transition
(@ pc:272608, curr_cell = check_cell) = the find_cell_list pick, structurally
identical to acdream's RunCheckOtherCellsAndAdvance -> FindCellSet -> SetCheckPos.
There was nothing to port; a swept advance would make membership LEAD by a frame.

- tools/cdb/find-cell-list-capture-aligned.cdb: re-capture reads the committed
  position from the set_frame that follows change_cell (cell+position same instant).
- Fixtures/find-cell-list-threshold.log: replaced with the aligned capture.
- ThresholdPortalCrossingReplayTests / FindCellListConformanceTests: rewritten from
  documents-the-bug to assert retail truth (per-segment / per-indoor-pick equality).
- handoff + notes + README + memory: banners correcting the disproven premise.

Still open (NOT indoor membership, which is DONE): outdoor->indoor 0031<->0170 entry
conformance (needs landcell + building stab in the gate cache); master-plan cleanups
(delete CheckBuildingTransit, unify find_env_collisions, demote ResolveCellId) refactor
working retail-faithful code -> need explicit user approval.

Conformance 60 pass / 1 skip / 0 fail; full Core 1309 pass / 5 fail (pre-existing
2 BSPStepUp + 3 door-collision = P2) / 1 skip.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
Erik 2026-06-03 18:54:27 +02:00
parent db94cb1c90
commit 9017107960
7 changed files with 197 additions and 64 deletions

View file

@ -167,7 +167,21 @@ evidence. **Do NOT design or code a P1 membership "fix" before the production-pa
RED/GREEN is read.** The P0 `..._DivergesFromRetail_PendingP1` test is a UNIT-level pin only, NOT
evidence of a production divergence.
## ✅ RESOLVED — the production path DIVERGES (the "probe artifact" hypothesis is FALSIFIED)
## ⚠ SUPERSEDED 2026-06-03 — the "production path DIVERGES" conclusion below was a CAPTURE ARTIFACT
The section below concluded the production path genuinely diverges (0/11 → "port the swept curr_cell
advance"). **That is wrong.** The 0/11 came from a one-frame skew in the cdb golden:
`CPhysicsObj::SetPositionInternal` calls `change_cell` (`acclient_2013_pseudo_c.txt:283456`) BEFORE
`set_frame` writes `m_position` (`:283458`), so the original capture paired each frame's NEW cell with
the PREVIOUS frame's position (`golden_picked[i] == geom(golden_position[i+1])`, all 22 rows). An
aligned re-capture (`tools/cdb/find-cell-list-capture-aligned.cdb`, position read from the following
`set_frame`) makes the production gate read **9/9 with NO code change** — acdream's center-only
`point_in_cell` pick already IS retail's true per-frame membership. Canonical corrected finding:
`memory/project_retail_membership_criterion.md` + the RESOLVED banner in
`docs/research/2026-06-03-p1-membership-swept-advance-handoff.md`. The text below is retained as the
investigation trail.
## ✅ (HISTORICAL) RESOLVED — the production path DIVERGES (the "probe artifact" hypothesis is FALSIFIED)
Built `ThresholdPortalCrossingReplayTests.ProductionPath_IndoorCrossings_DivergeFromRetail_PendingP1`
(replays the golden indoor `0170↔0171` segments through the REAL `ResolveWithTransition` — engine