docs(overhaul): prove replay projection cause and contract permanent correction

docs/architecture/retail-divergence-register.md

@@ -216,7 +216,7 @@ readiness/requeue adaptation. See
 | AD-102 | **Filed 2026-08-15 at Campaign CC slice CC4 (the Heritage page's Viamontian button and the Town page's Sanamar button).** Retail gates BOTH controls behind `CPlayerSystem::AccountHasThroneOfDestiny`: `gmCGHeritagePage::ListenToElementMessage @ 0x00483860` shows `MakeToDWarningDialog` instead of selecting Viamontian (element `0x100003c3`) for a non-ToD account, and `gmCGTownPage::ListenToElementMessage @ 0x0047c480` does the same for Sanamar (element `0x1000040b`, `startArea` index 3 — also the reason `CharGenState::RandomizeStartArea`'s ToD-aware `RandInt(3 or 4)` bound exists). acdream's `ChargenOptions` (CC1) carries no account/DLC-ownership signal anywhere in the model, so both controls ship WITHOUT the gate — every installed heritage/town in `Options.HeritagesById`/`Options.StarterAreas` is always selectable, matching what a ToD-owning account would see. | `src/AcDream.App/UI/Layout/CharacterCreationHeritagePage.cs` (`HeritageByButtonId[0x100003C3u]`); `src/AcDream.App/UI/Layout/CharacterCreationTownPage.cs` (`StartAreaByButtonId[0x1000040Bu]`, `Randomize`) | ACE's server-side `CharacterCreate` handler never checks ToD ownership either (the field is purely a retail-client UI gate), so accepting the selection unconditionally never produces a request the emulator would reject; adding an account-ownership model to CC1's DAT-only `ChargenOptions` is out of this slice's scope and would need its own design (where does the "ToD owned" bit come from — account service, launcher config, a new env flag?). | None observable against ACE. A future retail-parity gate that specifically checks "does a non-ToD account get warned off Viamontian/Sanamar" will fail until an account-ownership signal exists to gate on. | `gmCGHeritagePage::ListenToElementMessage @ 0x00483860`; `gmCGTownPage::ListenToElementMessage @ 0x0047c480`; `gmCGTownPage::SetTown @ 0x0047c360`; `CharGenState::RandomizeStartArea` (DoRandom case 4, `RandInt(hasToD ? 4 : 3)`) |
 | AD-99 | **Filed 2026-08-15 at Campaign LA gate round 2 finding 1 (character-select Exit button).** On a confirmed Exit, acdream closes the client through the existing graceful window-close path (`d.Window.Close`, the same seam `GameplayInputCommandController`'s in-world Escape fallback already uses) instead of retail's real post-confirm behavior: `RecvNotice_CloseDialog`'s case-1 arm queues UI mode `0x10000009`, which `gmEpilogueUI::Register` claims — a brief epilogue/farewell screen — before the process actually terminates. The confirmation dialog itself (`MakeConfirmExitDialog`, its exact `ID_CharacterManagement_ConfirmExit` text, and the `m_confirmExitDialogContext != 0` re-entry guard) IS ported faithfully; only the post-confirm destination differs, the same shape as AD-74's Options-panel exit. | `src/AcDream.App/UI/Layout/CharacterManagementUiController.cs` (`RequestExit`); `src/AcDream.App/UI/RetailUiRuntime.cs` (`CharacterSelectionRuntimeBindings.RequestExit`); `src/AcDream.App/Composition/InteractionRetainedUiComposition.cs` (`d.Window.Close` binding) | acdream has no `gmEpilogueUI` port (out of scope this round); reusing the ONE existing graceful-shutdown seam keeps `disconnected`/`exited` status events firing through `GameWindow.OnClosing` → `CompleteShutdown` rather than inventing a second shutdown path, per explicit direction for this finding. | A user confirming Exit sees the window close immediately instead of retail's brief epilogue screen; a future feature wanting to reproduce that screen (or an intermediate "logged off, returned to character select" state) has no seam yet — same gap class as AD-44. | `gmCharacterManagementUI::MakeConfirmExitDialog @0x004ed250`; `RecvNotice_CloseDialog @0x004ed760` case 1; `gmEpilogueUI::Register(0x10000009)` @0x0047a680; `gmCharacterManagementUI::OnAction @0x004ed410` (Escape key, unported — button-only this round) |
 | AD-113 | **Filed 2026-08-25 at Campaign CT slice CT-GF1 (client-wide retained-UI ancestor clip).** Porting retail's `UIRegion::DrawHere @0x0069FA30` ancestor-clip intersection (an element's screen rect is intersected against the FULL inherited clip-rect chain and the subtree is skipped when the intersection is empty — the `var_24` gate @0x0069FB8E) as `UiElement.ClipsChildren`'s new client-wide default (true, threaded through the pre-existing `UiRenderContext.PushClip`/`PopClip`) needed one deliberate opt-out: retail spawns a menu's dropdown popup as a SEPARATE top-level region (`UIElement_Menu::MakePopup`), clipped only by the screen, while acdream's `UiMenu` draws its popup INLINE from the owning button in a second traversal (`OnDrawOverlay`, pre-existing, "regardless of this element's position in the tree" by its own doc comment). Without an escape, the new ancestor clip would wrongly cut off a popup that legitimately extends outside its own (possibly short) owning window — e.g. a channel dropdown opened upward past a short chat window's top edge. `UiElement.ExpandsClipForPopup` (default false) resets the accumulated clip to the full CANVAS rect (0,0,ScreenSize) — SCREEN-clipped, not truly unbounded, matching retail's own popup region (`UIElement_Menu::MakePopup` spawns a top-level region bounded by the screen) — for exactly the `OnDrawOverlay` call of an opted-in element (`UiRenderContext.PushClipUnbounded`, sharing the existing clip stack; corrected from an earlier `null`/unbounded clip at the CT-GF1 fix round); `UiMenu` overrides it true, paired with `ClipsChildren => false` so its own out-of-bounds `OnHitTest` union (the popup occupies `ly < 0` or `ly >= Height` depending on open direction) stays reachable through the same early-bounds gate that now defaults on for every other element. | `src/AcDream.App/UI/UiElement.cs` (`ClipsChildren`, `ExpandsClipForPopup`, `DrawOverlays`); `src/AcDream.App/UI/UiRenderContext.cs` (`PushClipUnbounded`); `src/AcDream.App/UI/UiMenu.cs` (the two overrides) | The popup is the ONLY overlay-drawing widget in the tree today (grep-confirmed: exactly one `OnDrawOverlay` override client-wide), and it already renders on top of the whole UI by construction (the overlay pass beats even rect backgrounds), so exempting it from the ancestor clip matches its existing "regardless of tree position" contract rather than introducing new behavior. | A future `OnDrawOverlay` override that is NOT a screen-anchored popup (e.g. an in-place highlight meant to stay window-clipped) would silently escape every ancestor's clip if it left `ExpandsClipForPopup` at its default; the opt-in default direction makes that the exception rather than the rule, but a widget that WANTS window-clipped overlay content has no dedicated seam beyond simply not overriding the escape. | `UIRegion::DrawHere @0x0069FA30`; `UIElement_Menu::MakePopup`; the register's own AP-201 retirement note (the FIRST `ClipsChildren`/`PushClip` port, for `UiScrollablePanel`'s viewport) |
-| AD-118 | **ATTRIBUTION REOPENED 2026-09-05 (#472, S5 packet §39): live `newmethod=1` selects matrix-based rays while the replay implements the legacy branch. The earlier x87-only explanation below is not established until the mixed-projection harness defect is isolated; no production change or new accepted failure is implied.** **Filed 2026-09-03 at Campaign OVERHAUL v2 S3 (docs/ISSUES.md #458, resolved).** The walk's portal-view EDGE PLANES are built from acdream's own float projection (`WalkCopyView` on `IWalkRayCaster`'s unprojected rays; the replay context's `Matrix4x4` view-proj), while retail builds them in `Render::copy_view @0x0054dfc0` from D3D-transformed screen points under x87 arithmetic. The planes agree to about 0.5 % (measured live at the Holtburg doorway: the fourth door-edge plane's clip height at the ring-21 block `a9c9` is 300.4/310.2 m in retail vs 298.8/308.5 m here — a slope ratio of 0.05104 vs 0.05042, roughly 0.35 px of projected door-vertex position at 720p), which is invisible everywhere except at a block/cell corner that sits within that margin of a plane: there `Render::block_check`'s four-corner unanimity test can flip PartiallyInside↔Outside for a far LOD block (one corner inside for us, outside for retail), admitting or skipping a whole distant land block retail decides the other way. | `src/AcDream.App/Rendering/Walk/WalkCopyView.cs` (per-edge plane build); `src/AcDream.App/Rendering/Walk/WalkVisibilityMath.cs` (`FillClipHeights`, `CornerPlaneCheck`, `BlockCheck`); `tests/AcDream.App.Tests/Rendering/Walk/WalkTraceReplay.cs` (the replay's projection) | Bit-exact agreement would require reproducing D3D's x87 vertex transform and `copy_view`'s exact rounding order; the algorithm, sentinels, loop shape, z slab padding and verdict logic are all ported verbatim and reproduce three of four capture poses exactly at the eight-kind transcript level. | A land block at ≥ 20 rings whose corner lies within ~0.5 % of a doorway edge plane may be drawn where retail skips it (or vice versa) — one far, low-LOD block, no known visible artifact; the `WalkTraceConformanceTests.Oh_doorway_still_first_frame_diff` row stays `KnownFailure` as the standing example. | `Render::copy_view @0x0054dfc0`; `Render::get_clip_height @0x0054cff0`; `Render::block_check @0x0054dc50`; `LScape::draw_check_blocks @0x00505f80` (the `if (esi_3 != 0)` residency gate and the per-view `block_check` call @0x005061df); captures `docs/research/2026-09-01-overhaul/oh-capture/holtburg-doorway-still.blockcheck.log` / `.blockset.log` |
+| AD-118 | **DIAGNOSTICALLY DISPROVEN 2026-09-05; permanent test correction/review pending (S5 packet §40).** The observed #458 doorway and #472 stair differences came from the replay's legacy rays paired with a different forward projection; frame-entry pose timing also mattered. Captured newmethod=1 selects the matrix branch. The corrected matrix plus next-marker pose reproduces all 25 complete OH/capture frames exactly; the old x87-only attribution is superseded. | `tests/AcDream.App.Tests/Rendering/Walk/WalkTraceReplay.cs`; `WalkOracleTrace.cs`; shared conformance Recorder | No production deviation has been established by these fixtures. Retire this row's acceptance rationale with C1c's permanent discriminating proof; ordinary floating-point differences are not permission to accept a transcript mismatch. | #458's KnownFailure remains only until the permanent default replay row passes; no new failure accepted. The historical evidence remains in docs/ISSUES.md, explicitly superseded. | `Render::copy_view @0054dfc0`; `PrimD3DRender::ScreenToViewTransform @0059aa40`; `SmartBox::RenderNormalMode @00453aa0`; packet §§39–40; `s5-c1b-projection-diagnostic.txt` |
 
 ---