356 commits

Author	SHA1	Message	Date
Erik	1688863366	fix(vendor): the range watcher measures retail's cylinder-gap — the acceptance-band self-close is dead (Fable, from the live trace) ... The vendor-verify gate's trace proved the entire walk-to-use chain succeeding — arrival natural, Use dispatched, UseDone, the full 117-item ApproachVendor — and the panel still never appeared: the range watcher's plain center-distance shortcut (AP-160) closed the session the same frame it opened. The walk stops where the server accepts (cylinder-gap: center minus both radii), which lands ~4.3 m center against the vendor's authored 3 m — inside the acceptance band, outside the watcher's bare-center check. EnforceRange now measures cylinder-gap with both radii resolved through the SAME ResolveObjectTableHost seam the movement arrival uses — the seam whose absence was AP-160's original justification, created by the previous commit's fix. The watcher and the walk agree by construction. Unresolvable hosts degrade an operand to center distance (close-early only, never holding a session ACE ended); heights pass 0 (the host surface exposes radius only). AP-160 narrowed; #352 files the deferred cylinder-vs-center discriminating unit test (needs a 38-member host fake; the live gate covered the behavior today). Clean-room complete solution: 11,536 passed / 4 skipped / 0 failed. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-08 17:24:49 +02:00
Erik	02b735ba4a	fix(vendor): evidence-based pass — max-first stack ceiling; the local player resolves never-animated MoveTo targets ... Both chains pinned by the live [vendor-diag] run (vendor-diag.log) after three code-reading rounds each failed: The split bar: ACE serializes descStackSize=1 for EVERY browse row (live wire, log 343-348) — the R1-era "ACE never populates desc" claim is retracted with the line quoted. Retail's vendor sites read pwd._maxStackSize directly (four sites, incl. UpdateItemsList @0x004c1ea0 stamping min(remaining, _maxStackSize)); ResolveAuthoredStackSize flips to max-first for its vendor-only consumers. Taper ceiling 1000, scarab 100, seed 1 for exempt. Pricing still reads the desc (per-1 values on ACE). Walk-to-use: the local player's getObjectA seam was bound to TryGetPhysicsHost, which resolves only INSTALLED physics hosts — a never-animated vendor has none, so TargetManager.SetTarget got null, the MoveToObject armed with zero nodes, and UseTime never dispatched. The log's natural=False completions were the user's own movement keys (retail-correct input-edge cancels); attempt 4 worked because the greeting animation had installed a host. RuntimePhysicsState gains the retail CObjectMaint::GetObjectA seam (bound canonical resolver with installed-host fallback); the graphical host binds the SAME lazy-minimal-host resolver every remote already uses — whose own doc comment names this exact never-animated hazard. The reservation release was already correct (2b premise refuted with evidence); the production-wiring invariants are now pinned by four new tests including the pre-fix pathology as a permanent sabotage control. AP-169 rewritten a second time, honestly. The [vendor-diag] probe family (ACDREAM_DUMP_VENDOR) lands env-gated for future live triage. Clean-room complete solution: 11,536 passed / 4 skipped / 0 failed. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>	2026-08-08 17:17:04 +02:00
Erik	d003449bb4	fix(vendor): re-gate residuals — MaxStackSize is the stack operand, wire-authored use radius, purse summaries ... R1 the split bar's operand is the item's authored MaxStackSize — three retail sites read pwd._maxStackSize directly (InqListSlotCount pc:200052, buy-button cases pc:203996/204086) where ACE never fills the desc stack and standard stock is unlimited. Threaded StackSizeMax end to end with one shared resolver; the two literal _maxStackSize sites are now byte-exact; AP-165 retired, AP-169 corrected. R2 walk-to-vendor never opened because GetUseRadius used an UNCITED 3m Creature heuristic as the local stop distance while ACE's poll demands the authored radius (default 0.6 m) — the walk stopped and the Use fired far outside acceptance. Now reads the wire-authored spawn UseRadius with ACE's exact fallback; heuristic constants deleted. A first sabotage attempt was non-discriminating (coincidental 0.6) and was corrected — the discriminating version is what landed. R3 the Buying/Selling purse summaries ("Buying %d %s worth %hsp" / "You have %hsp") recovered from the binary data segment where BN mis-attributes the Buy-side literal; wired to staging and money changes on the four authored text elements; AP-166 narrowed to the pending-sell highlight. Clean-room complete solution: 11,528 passed / 4 skipped / 0 failed. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>	2026-08-08 15:23:10 +02:00
Erik	68568a3a59	fix(vendor): grand-gate findings — wire-truth container counts, the live split bar, arrival-gated use, prepend-order race ... Four live findings, each with the paper-verification failure named: G1 the container-capacity guard counted containers by a local type/capacity heuristic that over-classifies ordinary items; retail buckets from the wire's ContainerProperties at insert. Now reads ClientObjectTable's existing ContainerTypeHint (AP-168 narrowed to the shop-stock half; a pre-check must never false-block). G2 the amount bar never showed live because ACE never sets StackSize on browse listings — DescStackSize is null for every real vendor item and the C4 paper test hand-set the field, bypassing the materializer. The materializer now falls back to the packed supply count (AP-169, ACE adaptation); the new test drives the REAL materializer. G3 an out-of-range Use now dispatches ON ARRIVAL (pickup's shape): ACE's HandleActionUseItem only opens the vendor when the Use finds the player in range — a click-time send is greeted and dropped (AP-170, ACE adaptation; retail's server walks the player, ACE does not). G4 bought items appended because ACE's placement echo (UIQueue) can beat the CreateObject (SmartboxQueue) — cross-queue, no ordering guarantee — and the early echo was silently dropped. ClientObjectTable now stashes unresolved placements and replays them at Ingest: buys land at the retail list head. No register row — this RESTORES parity. Clean-room complete solution: 11,521 passed / 4 skipped / 0 failed. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>	2026-08-08 14:03:57 +02:00
Erik	c68ad1e646	fix(vendor): 6b/6c review corrections — pre-send guards, accumulating staging, trade-note exemption, drag-over tab switch, full-stack sells ... All thirteen findings, each anchored in recovered bytes or pc reads: Buy All now runs retail's four PRE-SEND guards in order (pyreal and alt-currency affordability, container and item slot capacity; strings recovered from .rdata at 0x007b57b4/0x007b5750) — a rejected batch can no longer destroy the staged list. Staged adds ACCUMULATE with the 5000 cap ("I can't possibly sell you that much!..." @0x007b59d8) and the shop rows decrement/restore per RemoveFromShop. The max-value sell rejection exempts trade notes — the raw bytes at 0x005d1add are `not` (bitwise), not the pseudo-C's misleading `!`, and the early ret skips the min check too. BF_RETAINED gates selling end to end (the bit was already on ClientObject; AP-164's three claims were all false once traced — RETIRED). Dragging over the vendor window auto-opens the Selling tab per UpdateDragOver — with a correction to the review's own citation: token 0x100000cd is the SELLING page, the guard is "don't reopen the current tab." Sells are full-stack-only (three retail sites; "Cannot sell part of a stack" @0x007b57ec) and Sell Item acts on the global selection unconditionally. The confirm string gains its byte-true trailing '?', dies with the session, staged-row highlights repaint, dead guids unstage with retail's shopping-list notice, and move-to-use no longer walks to targets the dispatch would refuse. AP-162 narrowed, AP-164 retired, AP-167/AP-168 filed honest. Clean-room complete solution: 11,508 passed / 4 skipped / 0 failed. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>	2026-08-08 12:50:28 +02:00
Erik	92ea3977b6	feat(vendor): Slice 6b/6c — move-to-use, buy staging, selling; the vendor arc is functionally complete ... C1 an out-of-range Use now approaches first via the existing client-predicted BeginApproach (Pickup's far-range shape mirrored; retail's ItemHolder::UseObject @0x00588A80 has no range check and the dispatch stays immediate). C2 Add-to-List stages into the Buying tab via VendorStagingList (RemoveProfileFromList's two shapes, pc:200497-200537), Buy All sends ONE batched 0x005F and flushes staging on send exactly as retail does (SendShopEvent -> Flush, pc:204075-204076 — not UseDone-gated), and X-close over a non-empty staging list shows retail's confirm string recovered verbatim from the binary data segment (0x007b5bd8) through the existing dialog factory. C3 the Selling tab's list is the sole drop target (retail's single IsAncestorOfMe gate, pc:204229-204246); VendorSellAcceptability ports InqAcceptability with all rejection strings recovered verbatim from the raw data segment; the sell side prices with BuyPrice (retail's inverted naming: what the vendor PAYS) and 0x0060 carries no trailing currency field, unlike Buy. C4 the status-bar reproduction test PASSES against the production toolbar mount — retail's toolbar shows count + name with the split bar and NO price parenthetical (that figure is the vendor row's own cost text); no code change, the live gate referees. C5 pack order verified correct, untouched. Register: AP-161 narrowed to its two pre-existing cosmetic gaps; AP-162 extended over Buy All; AP-164 (non-sellable bitfield unmodeled), AP-165 (DescStackSize for _maxStackSize in the removal test, bounded), AP-166 (purse text + pending-sell highlight cosmetic) filed. Clean-room complete solution: 11,482 passed / 4 skipped / 0 failed. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>	2026-08-08 11:43:11 +02:00
Erik	3c9fc57adb	fix(vendor): Slice 6 review corrections — ownership-checked retire, live slider display, drag-proof shop rows, hardened buy reservation ... All nine findings from the buy-arc review, at root: F1 the materializer's retire pass re-checks ownership (guid->vendorId map; remove only while the live object's ContainerId still equals the recording vendor) — buying a player-sold UNIQUE no longer deletes the item you just purchased; the discriminating reparent-then-refresh test pins it. F2 the cost/name display subscribes to the live split state and shares ONE quantity computation with Buy (retail re-renders per slider tick: RecvNotice_StackSliderChanged 0x004C4500) — the sentence and the charge can no longer disagree. F3 shop rows never mint drag payloads (UiItemSlot.AllowDragSource gates both IsDragSource AND GetDragPayload — the second gate was caught by this pass's own test). F4 sendBuy reports whether anything was sent; a null-session buy cancels the reservation instead of leaking BusyCount forever. F5 the retire loop snapshots, isolates per-guid observer failures, and clears its tracking in finally and Dispose — teardown convergence can no longer wedge. F6 auto-select is retail's unconditional first-filtered-item shape (pc:201180-201184; the survival-check was our invention and the comment claiming otherwise is corrected). F7 non-stack buys clamp to quantity 1 locally (BuySingleItem pc:201669). F8 the Add button is hard-disabled until staging exists. F9 AP-161/162/163 rewritten to the post-fix reality. Clean-room complete solution: 11,378 passed / 4 skipped / 0 failed. The #350 render-ledger overflow observed this session is under separate investigation and is NOT addressed here. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>	2026-08-07 23:12:50 +02:00
Erik	97cf873870	feat(vendor): Slice 6 buy arc — shop items are real objects, vendor selection is THE selection, and Buy works (0x005F) ... Three ordered pieces in one landing (the shared controller/composition files carry all three; the internal order was 6.1 -> 6.2 -> 6.3): 6.1 VendorShopItemMaterializer diff-merges the shop list into the live ClientObjectTable on VendorState transitions (so client-local close and session teardown retire the entries too) and never claims a guid it did not add — ACE's UniqueItemsForSale can re-list a guid a player once held (AP-163 files the collision-skip; no retail counterpart traced). Right-click examine on shop items now routes through the ordinary appraisal path — the 5.4 F7c blocker dissolves with the table entries. 6.2 SelectionChangeSource.Vendor: row clicks, auto-select, and examine all flow through the canonical SelectionState; the status bar and the existing byte-faithful StackSplitQuantityState slider light up unmodified. VendorSplitPolicy is the single 0xDC41CB0 mask owner; the slider VALUE seeds to 1 for exempt items while maxSplitSize keeps the stack (the splitSize/maxSplitSize distinction, research §B.3). Selection clears at retail's actual site — VendorItemsUI::RemoveFromShop (pc:202848), not a CloseVendor-level clear that does not exist. 6.3 BuildBuy (0x005F): vendorGuid, count, (i32 amount, u32 guid) pairs, and the trailing alternateCurrencyId the REAL client sends (CM_Vendor::Event_Buy pc:689288) though ACE's reader ignores it. TryBuy rides the EXISTING J5.2 one-request-at-a-time reservation and completes on UseDone; the Buy button disables while a request is in flight. The reconciliation round-trip (money property update, inventory CreateObject, ApproachVendor refresh -> panel rebuild) is proven by a synthetic-inbound test against existing machinery — no new owner. Register: AP-161 narrowed (selection + examine residuals close; staging/Sell remain; double-click-to-buy confirmed ABSENT from retail with negative evidence cited — we match retail). AP-162 files the conscious no-client-side-affordability-precheck deferral. Clean-room complete solution: 11,368 passed / 4 skipped / 0 failed. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>	2026-08-07 20:28:26 +02:00
Erik	e602f84be2	fix(ui): Slice 5.4 review corrections — the dropdown renders from its authored popup, retail cost semantics, auto-select, icon overlays ... All nine review findings closed at root (one sub-item consciously deferred): F1 the category dropdown now draws: sprites/fonts wired and the popup geometry read from the vendor menu's own authored popup LayoutDesc 0x21000043 (root 0x1000034F — correcting the review's 0x1000014F transcription) per UIElement_Menu::MakePopup (pc:120705); chat's menu is untouched and its tests prove it. The new test drives selection through the REAL open/hit path the review flagged as bypassed. F2+F3 the selected-item cost display ports VendorItemsUI::UpdateItemsUI verbatim: quantity via the 0xDC41CB0 split-size mask (whole-stack for ammo, per-unit for groceries/components; mask lives at the toolbar SEEDING site pc:198784), plural names with retail's fall-back-to-singular (pc:409056 — correcting the review's "name+s" guess), full cost sentences with comma grouping and the player's coin total, and Buy/Add buttons that disable without a selection. F4 category switches auto-select the first filtered item (pc:201180). F5 icon underlay/overlay/effects + plural name forwarded from the already-parsed wire fields through VendorShopItem to the icon composer. F6 a DIFFERENT vendor opens on its own first category; same-vendor refresh preserves per the clamp. F7 scroll resets on rebuild and authored empty slots fill; the right-click examine route is consciously DEFERRED (shop items are not in ClientObjectTable and the appraisal panel hard-requires it — documented, not faked). F8 VendorState.Apply's fanout gets the same per-listener isolation as Close/Reset. F9 AP-110/AP-161 wording corrected ("quantity-correct pricing") and AP-161 rewritten to exactly the remaining conscious gaps. Clean-room complete solution with the #348 cursor fix in the same tree: 11,334 passed / 4 skipped / 0 failed. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>	2026-08-07 18:26:17 +02:00
Erik	c721830e71	feat(ui): Slice 5.4 — the authored vendor browse panel (LayoutDesc 0x21000012) ... The vendor window is retail's own: LayoutDesc 0x21000012, root 0x100000B7, found by enumerating all 101 layouts for the one containing both known tab controls and clinched by the root's Type 0x10000017 — the literal UIElement::RegisterElementClass id for gmVendorUI (pc:202075). Discovery evidence and the D0 read live in the research doc's new §B.4. D0 corrected two assumptions: retail's category "tabs" are a UiMenu DROPDOWN fed by a hardcoded 18-row ordered category table (ported bit-for-bit against our ItemType enum; list always scoped to exactly one category, first-present wins, selection preserved across refresh per retail's clamp), and the layout authors THREE tabs — Items (browse, this slice), Buying and Selling (staged-transaction review, Slice 6) — decision 4's "browse/Buy tab" names the Items tab retail's mode-2 OpenTab opens. The non-default tabs render and switch pages but stay inert, fenced in comments. VendorUiController mounts Items: category dropdown, icon-cell item row with the retained scrollbar, per-unit retail pricing via VendorPricing.SellPrice (the vendor-stock path VendorProfile:: VendorSellPrice feeds), name/cost on selection. The panel is a pure projection of VendorState — opens on populate, closes on clear; the close button's VendorState.Close() is its only permitted mutation. Nothing on the wire. AP-110 narrowed (vendor leaves the absent-panels list); AP-161 files the precise Slice-6 remainder (Buying/Selling unwired, Buy/Add buttons, InqAcceptability). Twelve controller tests on a real-dat fixture. Clean-room complete solution: 11,323 passed / 4 skipped / 0 failed. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>	2026-08-07 17:00:21 +02:00
Erik	609a2dfda0	fix(runtime/core): Slice 5.3 review corrections — retirement/transit close, per-unit pricing, guarded auto-close dispatch ... The adversarial review's three blocking findings, each fixed at root: 1. A vendor session now CLOSES when its entity retires (despawn, death, ObjectDelete) and at teleport BEGIN (HasPendingTeleportStart || IsTeleportActive at the existing per-frame seam — both hosts funnel through RuntimeWorldTransitState.TryQueueTeleportStart, which flips the pending flag strictly before activation). The previous permissive early-return stranded the session forever: panel pinned to a stale guid, ActiveVendorId swallowing Use for the rest of the session. 2. VendorShopItem carries the desc's stack size, and VendorPricing.PerUnitValue ports retail's stack-total division (VendorProfile::VendorSellPrice 0x005D1B00: <= 0 guard, integer division) — a stack of 50 arrows now prices per arrow, not at 50x. 3. VendorState.Close() guards its observer fanout with the dispatcher's catch-and-log semantics — a throwing panel listener can no longer propagate into the unprotected per-frame path. Register honesty rides along: the 0.6 m UseRadius fallback was acdream's invention (ACE's CheckClose has no fallback; retail passes the raw authored radius) — removed, the watcher now uses the raw radius and AP-160's citations are corrected and extended with the accepted-position-snapshot cadence; AD-72 files VendorPricing's double-vs-x87-extended narrowing (AD-33's class, bounded by the ±0.1 margin). Nine tests added. Clean-room complete solution: 11,311 passed / 4 skipped / 0 failed. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>	2026-08-07 16:15:57 +02:00
Erik	9796d71522	feat(runtime): Slice 5.3 — RuntimeInventoryState owns the vendor browse session ... The sole VendorState joins the J4.2 inventory owners: populated by the new 0x0062 ApproachVendor route (parse via VendorApproach, wire-to- domain mapping at the routing seam, silent-drop on malformed like every sibling), borrowed by both graphical and headless hosts, and torn down through the EXISTING ExternalContainer reset stage — session reset, portal-out, and logout all funnel through the one mechanism. Close is client-local per retail (nothing on the wire): a range watcher rides the existing per-advanced-frame publishMovement callback, using the vendor's own authored UseRadius (ACE's 0.6 m fallback when absent). The dormant ItemInteractionController ActiveVendorId seam is finally wired as a live delegate — real id while open, 0 the moment the session clears. AP-160 filed in this same commit: the watcher measures plain 3D center distance rather than retail's cylinder-gap, because Runtime has no per-NPC collision radius/height source; bounded sub-meter, client- local UI only. Twelve Runtime tests: populate/field mapping, vendor replacement, range clear + within-range retention, all three generation teardowns, the ActiveVendorId seam, malformed-event drop. Clean-room complete solution: 11,302 passed / 4 skipped / 0 failed. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>	2026-08-07 15:37:12 +02:00
Erik	fa0c053ebf	docs(physics): #347 closed WITHOUT a code change — retail's glide alternates exactly as ours does; AD-70 retired as a wrong inference ... The round-2 cdb capture is decisive: during a live retail glide, edge_slide fired ~1.5 times per find_transitional_position — the arm/move alternation's exact signature (3 entries on the arming tick, 0 on the moving tick) — with cliff_slide in lockstep, step_down at 2.5x, step_up 0, and every stack sample on our identical call path. cliff_slide's bytes match our port and ACE's (compare constant at 0x794610 verified 0.0), and the user could not distinguish the two clients side by side. The "retail redirects within the tick" premise misread round-1's set_sliding_normal cadence (per-event, not per-tick, so its 1:1 ratio with edge never discriminated anything). The alternation-tolerant assertion in Issue345SteepSlopeGlideTests is therefore the CORRECT retail-shape pin from both sides; its comment now cites the capture instead of calling the shape a residual. The #269 note is honest the other way: the hope that a within-tick port would explain that feel residual is withdrawn with the premise. The temporary Scratch347 diagnostic is deleted. Capture evidence: 345-glide-stacks.cdb.log (repo root, untracked, cited from the contract's RESOLUTION section). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 14:05:53 +02:00
Erik	ab89ebdf92	fix(physics): #345 — a grounded mover glides along a too-steep face; validate_walkable's return is scoped as retail's bytes scope it ... Retail's OBJECTINFO::validate_walkable @0x0050d010 initializes its return slot to OK (0x0050d025) and assigns ADJUSTED only inside the below-plane guard, immediately after the push executes (0x0050d249). The guard-fail path — grounded, OnWalkable, plane too steep — jumps past the contact write, the push, and the assignment (0x0050d1b9 -> 0x0050d251): retail deliberately IGNORES the steep plane at primary validation so the insert proceeds, the step-down phase fails on the steep landing, and the edge family produces the per-tick lateral glide. ACE flattened this into an unconditional return Adjusted (ObjectInfo.cs:169) and we inherited it; our TransitionalInsert then retried the byte-identical Adjusted forever — the user's stop-instead-of-slide. Evidence chain: the user's retail observation (the axiom), the live cdb glide profile (edge_slide/cliff_slide 594 each in lockstep, step_up 0), the D0 implementer's correct STOP (fixtures reproduced the stuck fingerprint while faithfully executing the ACE-shaped reading — refuting the reading, not the code), and the capstone byte-decode both Opus reviewers re-derived independently, including the stack-slot frame arithmetic and every ret site's eax. The conformance fixture is the live topology: flat and steep terrain triangles sharing ONE cell's diagonal (a cell-boundary face does NOT reproduce the loop — the cell-scoped primary sample never validates a neighbour's triangle — and is pinned as supplementary). Sabotage: restoring the unconditional Adjusted reds the discriminator with the exact stuck position (0.325 m lateral, 28/30 stuck ticks vs 2.602 m / 14/30 fixed; reviewer B's independent five-angle table is monotone 10-85 degrees). Stuck ticks are counted from positions so the assertion survives the eventual probe strip. In-game glide gate PASSED 2026-08-08: "Well it works, we are sliding. I cant detect any speed change from retail." Filed alongside: #347 + AD-70 (our glide alternates arm/move at half retail's per-tick rate — retail redirects within the tick; next up by user direction), AD-71 (the guard's mutable WalkableAllowance operand vs retail's fixed is_valid_walkable global — now return-value-bearing), and the reviewers' named residuals in the #345 closure entry (placement-arm flip, other-cell coverage gap, EdgeSlide-less projectiles, ACE's server-side shared misport predicting remote drift-then-snap on steep terrain). The unported IsViewer arm of validate_walkable is noted in the D0 doc. Suite: clean-room complete solution 11,271 passed / 4 skipped / 0 failed; Core assembly re-run green after the review-driven test hardening. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 13:32:51 +02:00
Erik	064b82e94b	docs: AD-66's hover-look slope gate passed — the retired row's acceptance is complete ... Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 12:07:25 +02:00
Erik	10efb5b1f9	fix(physics): AD-66 relands — the push-out uses retail's bare radius; plant-then-lift complete (#341 closed) ... Third attempt, landed on evidence where the first two correctly refused: the ten-run stability gate passed 10/10 bit-identical (0x42667451, two clean-room cycles among the runs), the recalibrated golden's every value measured with derivations rather than guessed, and the historical measurement flip stands recorded as unexplained-but-unreproducible after 37 hunt runs plus these 10 found no divergence anywhere. The mechanism, completing the S4b byte-pin: validate_walkable plants the sphere at perpendicular r*N.z (byte-faithful, untouched); this push fires once per settle and lifts to tangent equilibrium dist=r, where the trigger goes quiet — retail's slope hover, arriving via the push exactly as the original substitution's own comment predicted retail had. Sabotage: restoring radius*N.z reddens the discriminating exact-value test verbatim. AD-65 conformance, the uphill no-flap guard, and the #331 absorb pin all green untouched. AD-66 retired (the campaign's last withheld row); AD-69's seam-frame correction deliberately unbundled, stays active as its own follow-up. Clean-room suite 11,267 / 4 / 0 — the suite's two AD-66 skips are gone. User's "port the retail pair" decision is now fully executed; the hover-look slope gate is the remaining acceptance. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 12:01:15 +02:00
Erik	c5b406c2b1	docs: AP-156's scale question decided by the user — keep ours, permanent safe-direction divergence ... Retail floods at authored size regardless of placed scale, which under-registers ENLARGED objects into neighbouring cells (a walk-through edge case retail genuinely has). The user chose not to import that bug for byte-fidelity. Closed; not a cleanup candidate. This was the campaign's last open decision. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 09:33:44 +02:00
Erik	c5443b3df9	test(physics): S6 — the camera provably reaches both PerfectClip TOI tails; contained, not dormant ... AP-83/AP-91 claimed no current mover sets PerfectClip. The containment proof found the opposite and the contract's honest-fallback fired: the camera probe (the sole production setter) reaches BOTH ACE-derived tails live — the viewer exemption is creature-only, the shadow-list walk is unconditional, and static scenery with authored primitives is a real non-creature population. Every reach is now recorded (camera-live silently; any non-viewer mover loudly, one-shot), so a future flag change cannot exercise unreviewed ACE-derived math silently. Four tests drive the camera's exact call shape both ways; the sabotage was intelligently adapted — there was no existing cut to disable, so it flips the one axis the proof depends on (IsCreature) and asserts reachability inverts. Both register rows rewritten CONTAINED-not-dormant with severity narrowed to camera-feel (the probe never commits a PhysicsBody). Landing note: diagnostics-only diff (two guard calls + counters + corrected stale comments), verified directly by the session lead rather than a review cycle — the review budget went where behaviour changed tonight. Campaign S CLOSES with this landing: S1A/S1B/S2/S4/S5/S6 done, S3 cancelled, three user-passed gates, one honestly-open item — AD-66's reland, twice self-refused by its own stability gate, blocked on the #341 codegen-shape measurement instability whose ABA evidence and first discriminating experiment are filed. Clean-room suite: 11,257 passed / 6 skipped / 0 failed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 09:21:40 +02:00
Erik	9671af0273	fix(physics): S2 — static publication emits authored Spheres as Spheres (AP-155 narrowed) ... Both static sites (LandblockPhysicsPublisher, the headless-only LandblockPhysicsContentBuilder) emitted an authored Setup Sphere as a base-anchored Cylinder of radius r and height 2r. The live path emits a Sphere for the same data, so the same object collided differently by arrival route, and the narrow phase met a flat cap where retail meets a curved surface. Both sites now mirror ShadowShapeBuilder.FromSetup's Sphere block exactly. Combined Opus review: PASS. Its numeric verification of the dispatch test's geometry (head-sphere clearance 0.201 m for the true sphere; the cylinder counterfactual inside by 0.10 m XY with the Z band overlapping) is what makes the discrimination claim more than a sabotage anecdote, and its F8 finding is applied: the test now carries a POSITIVE control — aiming straight through the boulder's centre must block — so a membership/seed regression can no longer masquerade as a curve-hit pass. F4 applied: CylHeight is asserted, not inferred (the C4 lesson). F3 applied: the deleted Quaternion.Inverse base composition is recorded as internally coherent for the old cylinder's world-Z axis — the defect was the shape TYPE, not that rotation math. The review also verified the deleted-cylinder blast radius: the F2 overlay's drawn span is IDENTICAL for both shapes (old [c-r, c+r], new [c-r, c+r]); the flood sphere's centre rises by exactly r, which cannot change outdoor membership (XY rectangle) and lands the indoor half on Session B's dungeon gate alongside S1B; and the sphere-branch flood is now pinned uncapped by a genuine eleventh-shape A/B test. PublishStaticCollision — the headless static path — gains its first test ever. AP-155 is NARROWED, not deleted (review F13): the has-BSP source split (entity.MeshRefs vs setup.Parts + AnimPartChanged) survives and keeps the row active. The shared-primitive-emitter refactor that would make route independence a compile-time property is the filed follow-up (review F20). Population: 3,506 of 5,935 installed Setups, structurally equal to AP-157's third-branch count (byte-identical classifier — three independent routes agree: 3,605 - 99 = 3,506). Clean-room suite at implementation: 11,253 passed / 6 skipped / 0 failed on landed S1B. Post-review-hardening: Publisher tests 25/25, Content tests 2/2, both green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 08:07:02 +02:00
Erik	b3e43d22c9	fix(physics): S1B — indoor cell membership admits on the part BOX, as retail does (#335, AP-159 narrowed) ... CellTransit.FindTransitCellsBox ports CEnvCell::find_transit_cells' part-array overload @0x0052cae0 line-for-line: per-portal x per-part order, the sphere cheap-reject at F_EPSILON+radius, the box admit whose "Straddle or crossing-side" rule is exactly retail's `eax != side` under the PDB Sidedness enum, leads-outside placed AFTER the admit, the unconditional unloaded-neighbour hint without the sphere overload's re-test, the destination box_intersects_cell gate with its deliberate no-break, and add_all_outside_cells after the loop. The box-vs-cell BSP traversal lands in BOTH representations behind the flat-authoritative dispatcher with a graph referee whose 20,000 installed comparisons are pinned by assertion (review F5), zero mismatch. Dual Opus review: PASS on both lenses. The mandatory D0 pseudocode pass caught that the contract's own supplementary note misattributed the box block to the sphere overload — it belongs to a SECOND check_building_transit overload @0x0052c680, whose portal-side convention is INVERTED and whose admit differs; the pseudocode doc now records that trap plus two byte confirmations made at review: which_side @0x00444720 is strictly > eps for POSITIVE, and intersect_box's in-plane early exit returns CROSSING(3) (jp @0x005aa1bc -> mov eax,3), settling review items b1/b2 for the future bridge porter. The bridge itself stays unported as AP-159's explicit remainder. The review also retired #335's severity premise honestly: "over- inclusive only, never a missed one" is wrong at production shape ratios, where the box (whole-vertex AABB) legitimately exceeds the sphere (physics-polygon root sphere). Measured, both populations: rigged (box << sphere) — 1,520 placements, 978 cells removed, 0 added; production-ratio (box >= sphere) — 950 placements, 20 removed, 1 ADDED through the loaded-neighbour gate, which is retail's direction, not a defect. The no-op guard (review F4) asserts removal is nonzero so an unwired admit cannot pass silently. Process note: the implementer authored against this session's worktree at bec5c69d, 25 commits stale — the recorded worktree-base class. All six files were byte-identical between bases, the diff transplanted losslessly, and every verdict-bearing run (referee, direction sweeps, this clean-room) was re-executed on current main. S2's uncommitted phase-1 edits were stashed for this landing so the suite verdicts exactly one changeset. Also untracks 341-slope-capture.jsonl (an accidental add) and gitignores it. Clean-room suite: 11,248 passed / 6 skipped / 0 failed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 07:46:57 +02:00
Erik	6b490aab8b	docs: morning gate G1 user-passed — AD-65 downhill slope feel accepted ... 'Slopes feels good' at the downhill/diagonal/jump-landing gate, on a launch whose capture self-verified the binary identity and the authored step heights. The overnight program's one owed visual gate is closed; Campaign S continues at S1B. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 06:50:58 +02:00
Erik	d73125d3b0	fix(physics): S4/AD-65 — the away-from-plane response snaps to the surface, as retail does ... Campaign S slice S4, the half that landed. Retail's CTransition:: adjust_offset @0x0050a370 branches on dot(offset, contactPlane.N) at 0x0050a4fa: moving INTO the plane subtracts the normal component (0x0050a529), moving AWAY calls Plane::snap_to_plane @0x00509c50 — which preserves X and Y and re-solves ONLY Z so the offset lies in the plane (the d terms cancel algebraically), no-op under the 0.000199999995f |N.z| epsilon. acdream ran the orthogonal projection in BOTH directions, shrinking downhill XY travel by cos^2(theta): 25% at 30 degrees, 50% at 45 — AD-65's recorded shortfall, now retired. The combined Opus review independently re-derived the algebra, the branch polarity, the epsilon's bit-identity (17b75139), and the sabotage magnitude (the re-instated projection yields X = 0.75 = cos^2 30 exactly), and verified the delta is 4 non-comment lines with the into-plane arm, the crease arm, and both no-plane arms untouched. Its blast-radius sweep found the away arm exercised but NOT discriminated by any pre-existing test — every one asserts lower bounds the snap over-satisfies — so the two new exact-value tests are the only discriminating coverage, recorded in the test's class doc, and the felt 33-100% downhill speed-up is the morning gate's one row. AD-66 (the push-out's bare radius) is WITHHELD: byte-confirmed twice, implemented, then pulled after the same clean-room binaries measured contradictory absorbed-tick outcomes flipping with nothing but test assert shape — issue #341 carries the observation matrix and the apparatus plan; its two exact-value tests are [Skip]-ed; the retained substitution's rationale is restored at the site per review F1, with the review's remaining findings (F2/F3/F4/F5/F6) applied and F8 filed as #342. AD-69 filed: the same block omits retail's get_block_offset seam-frame correction, deferred to the AD-66 relanding for attributability. #340 filed: a fifth load-sensitive flake. Review verdict: PASS. AD-65 is provably unable to reach the #341 anomaly's code path (the absorb scenario takes the crease arm). Clean-room suite: 11,239 passed / 6 skipped / 0 failed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 02:45:03 +02:00
Erik	5a317460c5	docs: restore AD-56 — the same revert that zombied AD-55 had silently DELETED this row ... Applying feedback_register_revert_resurrection to its own discovery: auditing every row in a8a7d64b's register hunk found the inverse defect in the same diff. The revert resurrected retired AD-55 AND deleted then-active AD-56 (the plumb-fall freeze adaptation, split out of TS-4 by the commit being reverted). Nothing ever restored it, and its condition came back to life when TS-4's Path-6 shortcut deletion re-landed for real at Slice 2B — so for eight days a live, test-pinned, deliberately-documented behaviour had no register row, which is 'a bug twice over' by the register's own rule. Restored verbatim from 5e2be19b with a provenance header. One revert, two silent register corruptions in opposite directions — the memory rule's audit step is not optional. AD section 50 -> 51. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 01:37:40 +02:00
Erik	a8e40cb62c	docs: re-retire AD-55 — its retirement was resurrected by an unrelated revert ... The Sledding constant has been the byte-confirmed cos(10 deg) = 0.98480775f in production since 252e8068 (2026-07-30), which also struck the register row. Five hours later a8a7d64b — reverting the UNRELATED TS-4 commit 5e2be19b — restored this file's older hunk and resurrected the un-struck row text while leaving the code fixed. The zombie row then cost tonight's session a full duplicate byte-derivation: the stale row said 0.99999536f was live, so the binary was re-read to prove what 252e8068's own commit message already contained verbatim. Tonight's derivation note is corrected to what it actually is — an independent confirmation of the week-old fix — and S5 collapses to this bookkeeping: no code change, no feel gate owed; the user has been playing on the fixed constant for a week. Process rule filed to memory (feedback_register_revert_resurrection): after any revert whose diff touches the register, re-verify EVERY row in the touched hunks; and before acting on a row's 'our code does X' claim, grep the cited file for the claimed expression first. AD section 51 -> 50 active rows. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 01:36:17 +02:00
Erik	52aea775b9	test(physics): AP-157 measured — CylHeight half retired, sorting-sphere half proven collision-unreachable; AD-55 byte-decoded ... Campaign S S1A, both outcomes the measure-first rule exists for. AP-157's CylHeight half is RETIRED as a non-divergence: retail's own cylsphere overload (CObjCell::find_cell_list @0x0052b9f0) copies localtoglobal(low_pt) + radius per cylsphere, capped at 10, and never reads height — retail collapses a cylsphere to a base-point sphere exactly as acdream does. The sorting-sphere half measured REAL against retail's registration set — 1,812 of 3,343 evaluated Setups (54%) fail containment at 1 mm, worst shortfall 18.135 m — and then PROVEN collision-unreachable: for this branch the flood spheres and the collision-test geometry are the same per-part Sphere list, so every omitted cell is one the entity's test geometry cannot reach, and retail's wider sorting-sphere registrations are narrow-phase rejects on retail too. Fix deferred to the next bake-schema revision rather than performing Slice I3 surgery for zero behavioural delta. The measurement test stays in the tree as the permanent record (population cross-checked against the dispatch test's independently-committed constants: 3,506 = 3,605 - 99). AD-55 is byte-decoded and RESOLVED against our constant: the binary loads qword [0x007c6b28] = pi/18 exactly and executes FCOS — retail's Sledding flatness threshold is cos(10 deg) = 0.984808. Our 0.99999536f is cos(0.17453 DEGREES): the radian literal misread as degrees, which makes the object-friction arm unreachable on real terrain (nothing is flatter than 0.175 deg). Evidence note carries the full instruction listing and the polarity of the test ah,0x41 / jp idiom; the one-line fix + conformance test is S5, queued behind the running implementation slice for build-slot reasons. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 00:57:36 +02:00
Erik	8c97084289	docs: close #338 — headline refuted by full-capture statistics; AD-68 files the real residual ... The three-site probe answered it in one run: prepare and publish carry the authored 0.600/1.500 to the publication candidate, and resolve receives exactly those values for the entire session after one early 0.400 reading. Re-reading the ORIGINAL 337-support.log with statistics instead of an eyeball: authored pair 111,248 lines, 0.400 pair 358. The filing was built on an early line of a 255k-line capture; the alleged mechanism (values never wired to the mover) does not exist. The 358 are AD-68, now registered: GetSetupMoverShape's placeholder (empty spheres -> legacy capsule, 0.4/0.4 steps) during an entity's async Setup-residency window, plus the local player's own seconds-long window between controller construction and publication-candidate adoption. Retail loads synchronously and has no such window. Left as-is deliberately: shrinking it is streaming work. The filing still paid for itself: three false doc-comment claims corrected in PlayerMovementController (retail '~0.4 m' twice, and an ApplyStepHeights writer that never existed anywhere in the tree — replaced with the real writer chain), retail's actual fallback pinned at 0.04 (CTransition::step_up @0x0050b655), and the resolve probe now prints the mover id, because the early 0.400 was most plausibly a REMOTE player — remotes also carry IsPlayer — and the guid rule (feedback_probe_identity_attribution) exists precisely to stop that misread. No production behaviour changed; nothing for the morning gate. AD section 50 -> 51. Suite 11,234 / 4 / 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 00:44:42 +02:00
Erik	1dc81710f3	docs: close #32 — local edge-slide user-passed; AD-67 filed for the kept cell-id write ... Both halves of #32 are now closed: remote at 204d0ae0 (user-passed 2026-08-04), local at 332045c7 (user-passed 2026-08-07 at the Rithwic cliff, on the first launch whose capture printed the fixed binary's own assembly path). The research doc carries the outcome banner: the live capture landed in decision-table row 1 verbatim and Section 7's fix shipped unchanged. AD-67 records the one deliberate residual: the narrowed SetContactPlane still writes ContactPlaneCellId, which retail writes only at init_contact_plane (0x0050e8ca). Kept on the research doc's own advice — our consumers want the current value — and not bundled into the fix commit, where a second behaviour change would have made the user's cliff gate ambiguous. AD section 49 -> 50. Section 3.5's blast-radius items stay open as watch items, now strictly MORE reachable than before the fix (last-known validity is narrower, so the StopVelocity recovery and phase-3 reset take their invalid branches more often). Carried onto Campaign S slice S4. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 00:38:02 +02:00
Erik	ea83b043df	fix(physics): delete the query-site broadphase reach filter (#333, closing #337) ... Transition.FindObjCollisionsInCell discarded a shadow candidate when |currPos - obj.Position| > sphereRadius + obj.Radius + movement.Length() + 2f obj.Position is the part ORIGIN; obj.Radius is the physics-BSP ROOT BOUNDING SPHERE's radius, measured about a centre AP-156 established is frequently metres from that origin (376 of 973 installed physics-BSP parts sit further from their part origin than half their own radius, worst 20.762 m). Geometry deep inside the real bounding sphere was therefore thrown away before BSPQuery ever ran: solid near the origin, permeable in a bounded shell beyond it. For the Neftet rock 0xC8766009 / gfx=0x01004751 the two points are 23.556 m apart, which is #337 — wedged on the plateau, jumps sinking into the mesh, corpses falling through. A live capture recorded 7,225 rejections on that one owner, every single one with wouldAcceptAtCenter=True. Deleted rather than re-centred. Retail has no distance pre-filter, disassembled from the PDB-paired v11.4186 binary (CodeView GUID 9e847e2f-777c-4bd9-886c-22256bb87f32) rather than read from Binary Ninja: CObjCell::find_obj_collisions @0x0052b750 walks shadow_object_list and calls CPhysicsObj::FindObjCollisions (0x0052b78b) UNCONDITIONALLY; its only early-out is insert_type == INITIAL_PLACEMENT_INSERT (0x0052b759). CPhysicsObj::FindObjCollisions @0x0050f050 contains no float compare at all. CPartArray::FindObjCollisions @0x00518180 is a bare do/while over parts, and CPhysicsPart::find_obj_collisions @0x0050d8d0 is two null checks plus a call. Retail's only spatial rejection is the BSP node bounding-sphere test inside the walk — correctly centred, which is exactly what the deleted filter was not. Re-centring it (carry BoundsCenter on ShadowEntry) would have preserved an invention retail does not have, including a +2f slack and a movement.Length() term with no retail counterpart, and left a second reach budget to be tuned forever. Retail's own cross-cell slack constant is F_EPSILON = 0.0002 m, not 2 m. The method's comment claimed the filter was "the analog of the part sorting-sphere early-outs inside retail's CPhysicsObj::FindObjCollisions — response-neutral, pure perf". Both halves were false and cost #333 and #337; it is replaced by the disassembly above. Gate: Issue333BroadphaseReachFilterTests drives the production path end-to-end (ResolveWithTransition -> FindObjCollisionsInCell -> CollisionTraversal) on a DAT-free fixture so it runs everywhere, as a discriminating pair. Sabotage-verified: restore the pre-check and OffCentreBspFloorStopsAFallingMover reaches z=37.800 — exactly the unobstructed fall, blockedAtLeastOnce=False — while CentredBspFloorStopsAFallingMover keeps passing. Without the control a fixture unable to fall would pass the first test for the wrong reason. Issue337's skipped TheBroadphaseAdmitsTheSurfaceTheMoverIsStandingOn asserted the now-deleted predicate and could never have gone green; it is rewritten as installed-DAT evidence pinning BOTH halves of the diagnosis and is no longer skipped. Perf measured, not assumed (Release, synthetic all-BSP cell, per ResolveWithTransition): at 38 candidates — the live maximum — 10.61 us -> 16.68 us (1.57x); at a deliberately unreachable 200, 17.34 -> 39.48 us (2.28x); ~0.16 us per additional candidate tested. Over 19,701 live [reach-q] samples the in-cell count is p50 = 9, p99 = 32, max 38. The ACDREAM_PROBE_REACH rejectedReach column is kept and is now structurally 0, so a post-fix capture stays comparable with the pre-fix one; dropping it would make the two incomparable. AP-158 retired (110 active AP rows). #333 and #337 closed pending the user's live acceptance at Neftet. Solution suite 11,231 passed / 4 skipped / 0 failed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-06 22:16:53 +02:00
Erik	13fcf38138	fix(physics): port retail's find_bbox_cell_list outdoor extent walk (#334) ... acdream had never implemented retail's SECOND cell-membership algorithm. CPhysicsObj::calc_cross_cells @0x00515230 tests HAS_PHYSICS_BSP_PS at 0x00515285 and jumps (0x0051528f jne 0x515305) to find_bbox_cell_list @0x00510fc0 for a BSP-bearing object; everything below that jump is the OTHER algorithm, CObjCell::find_cell_list, and that is all we had. Every object, BSP-bearing or not, was routed through it. That path's outdoor expansion is a HARD CAP of one cell in each direction. CellTransit.AddAllOutsideCells computes minRad = radius, maxRad = 24 - radius and adds at most the eight neighbours of the sphere's own cell, so for any radius >= 12 m both boundary tests are unconditionally true and the result is exactly 3x3. Widening the radius or adding a second sphere is mechanically incapable of adding a tenth cell. The user's live probe measured the consequence directly: standing inside a Neftet formation, inCell=2 exempt=2 reached=0 -- the geometry was not a candidate at all. The port. AddAllOutsideCellsFromParts is CLandCell::add_all_outside_cells @0x00533360 plus add_cell_block @0x005331d0: base landcell from the FIRST part's own adjust_to_outside, baseX/baseY within-block, each part's authored CGfxObj::gfx_bound_box re-fit through all eight corners (BBox::LocalToGlobal @0x005b2120), floor(v / square_length) where square_length = 0x7c920c = 24.0f, four accumulators seeded to zero, ONE rectangle unioned across all parts, FILLED, in GLOBAL lcoords so it crosses landblocks freely, clamped only to [0, 0x7f8). BuildShadowCellSetFromParts is find_bbox_cell_list's worklist. RegisterMultiPart dispatches on the same flag retail does, and BuildFloodSpheres' BSP arm is deleted rather than left unreachable. Disassembled from the PDB-paired 2013-09-06 binary, not read from Binary Ninja: BN mis-renders four separate constructs inside add_all_outside_cells alone -- a dropped `and eax,0xffff` on baseX, a neg/sbb/and select shown as identically zero, a wrong get_landcell argument, and both x87 flag tests as `unimplemented {test ah}`. ShadowPartGeometry pairs the BSP root sphere with the authored box so no resolver can answer one and leave the other call site to synthesize a substitute -- the AP-156 invariant applied a second time, since that split is what produced AP-156 and then this. The box comes from FlatGfxObjVisualBounds, already computed by exactly CGfxObj::init_end's algorithm and already in the prepared package: no bake change, no DAT re-read. Cost, measured over the installed DATs before any code was written: 1,258 physics-BSP GfxObjs, cells/object p50 4, p90 4, p99 12, max 49. The port is CHEAPER than the old 3x3 = 9 for 98.97% of them. Row totals (shapes x cells) over all 1,031 landblocks with BSP owners fall 97,173 -> 15,607 (0.161x); dense Arwic 0xC6A9 falls 342 -> 43. One landblock more than doubles. Precondition confirmed before pinning any expected cell set: 0x010046D8's box is 96 m x 96 m about cell (2,2) = 0x87640013, which independently corroborates the 3x3-centred-there diagnosis, and its rectangle does contain 0x87640011 and 0x87640019 -- the two cells the probe measured empty. Register: AP-156's outdoor half CLOSED and its risk column CORRECTED (it read "extra broadphase candidates, never a missed one", which generalised the indoor direction to the whole row and is why #334 sat inside it unnoticed). AP-159 + issue #335 file the unported indoor arm; AD-49 records the seed-time rectangle. Issue #336 files a fourth load-sensitive test flake seen once during the gate. Ten tests, every one sabotage-verified in both directions across eight mutations (dispatch, 8-corner refit, floor-vs-truncation, union-vs-per-part, map clamp, adjust guard, landblock clamp, box-path-for-everything). The strongest is an installed-DAT replay of the user's own probe evidence. Suite 11,208 -> 11,218 passed / 4 skipped / 0 failed; the +10 is exactly the new tests. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-06 19:07:06 +02:00
Erik	e6457cc849	fix(physics): close the AP-156 fix review — real containment oracle, type-level invariant, AP-158 ... Both review lenses PASSED; this is the cleanup, not a rescue. Evidence: docs/research/2026-08-06-ap156-review-closure.md (the review itself is committed alongside it as the received artifact). R1 — the load-bearing containment test could not fail. Its truth and flood values were two hand-copies of the same expression over the same part set, so the shortfall was algebraically identically zero for any DAT input. The oracle is now PHYSICS-POLYGON VERTICES — a different DAT field from the bounding sphere the builder emits, so the two sides can genuinely disagree. Sabotage-verified three ways after full cleans: dropping the bounds centre in production reddens it (428 Setups, worst 35.869 m on 0x0200129A, matching an independent out-of-repo sweep exactly); dropping only the scale on the centre reddens it (326); and corrupting the TEST's own bounds oracle reddens it (467) where under the shipped oracle that same corruption was invisible by algebra. Renamed accordingly. A6's stale "cap control" comment corrected: that loop is the test's own uncapped re-implementation and cannot observe a cap regression — the cap is covered in Core. R2 — the population was understated. 172 is AP-152's DISPATCH population; AP-156's is 530 BSP-bearing Setups, of which 525 have a flood sphere move and 428 fail vertex containment before the fix (412 at a 1 cm tolerance — the review's figure; the gap is 16 Setups between 1.4 mm and 10 mm, real geometry). 0 fail after, at any tolerance down to zero. Corrected in the AP-156 row, the section-3 header, the C5c handoff and two test docstrings. Dated review artifacts are left as written — "170 of 172" was correct for what they measured, and rewriting evidence to match a later measurement loses provenance. A1 — BoundsCenter = default reopened at the type what the commit closed at the seam. Dropping the default alone would NOT have closed the review's own scenario (a copied Cylinder call site would write Vector3.Zero explicitly and stay green), so ShadowShape's constructor is now private and BSP shapes are built only through ShadowShape.Bsp(..., FlatCollisionSphere localBounds), which takes radius and centre as ONE value and scales them together. There is no expression a caller can write that carries one and drops the other. 22 construction sites converted; the same sabotage now reddens 5 Core tests where the review's sabotage A reached 4, because both BSP producers share one scaling path. A2 — #333 is real and bigger than filed, and its retail question is answered. I disassembled CObjCell::find_obj_collisions @0x0052b750 from the PDB-paired binary myself (check_exe_pdb.py MATCH) rather than inheriting the claim: its only early-out is sphere_path.insert_type == INITIAL_PLACEMENT_ INSERT, then it calls FindObjCollisions on every unparented non-self shadow object UNCONDITIONALLY. Retail has NO distance pre-filter, so acdream's "+ movement + 2f" reach filter is an invention with no register row — filed as AP-158, carrying the disassembly, the F_EPSILON = 0.0002 m contrast, and the measured blast radius (118 of 477 unique installed physics-BSP GfxObjs exceed its ~2.5 m budget, 46 exceed 5 m). Active AP rows 109 -> 110. Recorded prominently in three places a reader will hit: TALL PROPS MAY SHOW NO VISIBLE CHANGE UNTIL #333 LANDS, and a null result at the connected gate is EXPECTED, not evidence against AP-156. LOW items. R3: the comment claiming the cited evidence justified the whole cap line is corrected, but int.MaxValue on the sorting-sphere branch stays — capping at 1 would take Spheres[0], and retail's one sphere is CSetup::sorting_sphere, a different DAT field; capping keeps the wrong field AND flips the substitution under-inclusive (#98/#168 direction). AP-157 already owns it. R4: acdream scales the flood sphere where retail's find_transit_cells never reads gfxobj_scale — added as a second residual on AP-156. R5: retail's slack constant carried into AP-158 and #333. A3: the per-call delegate allocation is back to a cached field, still derived from the single bounds resolver. A5: noted; b52967de's message cannot be amended. Gates: all 44 bin/obj deleted before every verdict-deciding build, each test run gated on a verified "Build succeeded" in the same invocation. Release build 0 errors / 21 pre-existing warnings. Complete suite 11,208 passed / 4 skipped / 0 failed — reconciles exactly with the e2b2d04c baseline; one test renamed, none added, removed or skipped. Nothing conflated with the known load-sensitive flakes #302 / #308 / #321. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-06 16:44:48 +02:00
Erik	b52967def3	fix(physics): AP-156 — flood the BSP sphere where the geometry is, not at the part origin ... The AP-152 retail review (docs/research/2026-08-06-ap152-review-retail.md) FAILED `4abd1b5e` and is right. `ShadowObjectRegistry.BuildFloodSpheres` took each physics-BSP part's ROOT BOUNDING SPHERE RADIUS (FlatCollisionAssetBuilder.cs:393 -> LiveEntityCollisionBuilder.cs:137) and centred it on the PART ORIGIN (ShadowShapeBuilder.cs:194), discarding the root sphere's own Origin. Re-measured independently against the installed client_portal.dat, reproducing the reviewer's numbers exactly: 376 of 973 physics-BSP parts have |origin| > radius/2, worst 20.762 m on a 27.708 m sphere (gfx 0x010036DD, Setup 0x0200129A). Over the 172 Setups AP-152 moved onto that path the emitted flood FAILED TO CONTAIN the object's own BSP sphere for 170 of them (73 CylSphere-bearing, 97 Sphere-bearing), worst shortfall 9.911 m on Setup 0x02000255 — whose one part's sphere sits 9.911 m above the part origin — and for 43 the post-AP-152 flood was strictly SMALLER than the pre-AP-152 one. Indoor flooding is 3-D (CellTransit.cs:601 routes every id & 0xFFFF >= 0x0100 candidate through FindTransitCellsSphere), so a tall prop or door slab was absent from EnvCells it physically occupies and therefore never a broadphase candidate there (TransitionTypes.cs:3763 iterates only entries already in the cell). That is the #98 / #168 class AP-152 exists to remove. Retail, re-disassembled from the PDB-paired binary (check_exe_pdb.py MATCH, CodeView GUID 9e847e2f-777c-4bd9-886c-22256bb87f32), every address resolved back through named-retail/symbols.json: CGfxObj::physics_sphere is [gfxobj+0x74] (physics_bsp is [+0x78], as CPartArray::CacheHasPhysicsBSP @0x00518110 reads at 0x00518127), and acclient pseudo-C 0x00534b5b assigns it BSPTREE::GetSphere(physics_bsp). BSPTREE::GetSphere @0x005397e0 8b01 mov eax,[ecx] ; BSPTREE::root_node 83c004 add eax,4 ; past BSPNODE::vfptr -> CSphere sphere So retail's per-part flood sphere IS the BSP root bounding sphere, ORIGIN INCLUDED (acclient.h: BSPNODE { vfptr; CSphere sphere; ... }, CSphere { Vector3 center; float radius; } -> radius at +0xc). CPhysicsObj::find_bbox_cell_list @0x00510fc0 adds the object's own cell and then walks the PART ARRAY: 0x00511012 call 0x518160 (CPartArray::calc_cross_cells_static), which dispatches [edx+0x7c] with (num_parts, parts, cellarray). Its EnvCell body, CEnvCell::find_transit_cells @0x0052cae0: 0x0052cb31 mov edx,[eax+0x20] ; CPhysicsPart::gfxobj (CGfxObj**) 0x0052cb36 mov esi,[ecx+0x74] ; physics_sphere (else +0x90 drawing) 0x0052cb4c add eax,0x30 ; CPhysicsPart::pos 0x0052cb5a call Position::localtolocal ; transform the sphere CENTRE 0x0052cb65 fadd [esi+0xc] ; only NOW the radius Retail transforms the centre through the part's own Position before it ever touches the radius. Carrying the radius alone is not an approximation of that; it is a different sphere. Changes: * `ShadowShape` gains `BoundsCenter` — the bounding sphere's centre in the shape's own local frame, scaled like LocalPosition and Radius. Zero for Cylinder/Sphere shapes, whose LocalPosition already IS their centre. * `ShadowShapeBuilder.FromSetup` gains a `physicsBspBounds` resolver that supplies radius AND centre from ONE call, replacing the placeholder radius plus a downstream substitution. `LiveEntityCollisionBuilder` now holds a single `Func<uint, FlatCollisionSphere?>` and derives its dispatch predicate from it, so the gate and the geometry cannot disagree and the radius cannot be taken while the origin is dropped. That split is what produced this bug; it no longer exists. * `FromLandblockBspParts` carries the centre too. A landblock-baked part array is the same CPartArray walk, so stair runs, fences and rock clusters had the identical defect. Both storage forms (flat BSP and the graph fallback) are covered. * `BuildFloodSpheres` places each sphere at partWorldPos + rotate(BoundsCenter, partWorldRot), composed exactly as the ShadowEntry rows are. * The 10-sphere clamp now applies to the CYLSPHERE branch only. Retail's clamp is inside CObjCell::find_cell_list @0x0052b9f0 (0x0052ba21 cmp eax,0xa / 0x0052ba28 mov ebp,0xa); the BSP walk has none and the sorting-sphere overload @0x0052b990 takes one sphere. 7 installed Setups carry more than 10 physics-BSP parts (max 49, Setup 0x02001A91) and their tail parts were dropped from the flood entirely. Without this the new containment assertion would have covered shapes production never floods from. Register. AP-155 was two divergences with different code paths, populations and gates under one id; it is NARROWED to its static-publication half and its flood half is split out as AP-156 WITH ITS DIRECTION CORRECTED. AP-155(b) recorded the approximation as over-inclusive — "floods MORE cells rather than fewer, the safe direction for membership" — and that false direction was the stated reason the residual was safe to defer. It was under-inclusive for 170 of 172. AP-156 records the correction, this fix, and the one genuine residual: acdream's sphere-vs-portal traversal where retail walks each part's sphere against the cell's own portal planes. AP-155(b)'s "acdream approximates retail's bounding BOX" was wrong too — find_bbox_cell_list forms no box. AP-157 filed for the review's F4: retail's third branch floods from ONE CPartArray::GetSortingSphere @0x00518b00 ([partArray+0x54]+0x70 = CSetup::sorting_sphere; 4,154 of 5,935 installed Setups carry a non-zero one) where acdream floods from every Sphere shape, and acdream's cylinder flood ignores CylHeight. Deliberately NOT bundled here: different branch, disjoint population, different live gate. Active AP rows 107 -> 109, literal count. Tests. Both flood tests the review named substituted a CONCENTRIC Radius = 14f at LocalPosition = Zero — the one configuration in which the defect cannot appear. Every fixture is now off-centre by default, and `FromSetup_CylSphereAndBspSetup_FloodsTheBspFootprint` drives the production `physicsBspBounds` seam instead of hand-substituting. Five new facts: the flood centres on BoundsCenter not the part origin; it rotates BoundsCenter by the part rotation; it caps cylspheres at ten but never the BSP parts; the landblock path carries the scaled centre in both storage forms; and an installed-DAT containment sweep asserting every emitted BSP flood sphere contains that part's real bounding sphere at entity scale 1.75, behind four external controls — 973 parts, 376 off-centre, 172 affected, and 170 would-fail-if-the-origin-were-discarded, the last of which fails if the population ever stops exercising the field. Nine sabotages, each reverted and re-verified: A drop BoundsCenter from the flood -> 3 Core B rotate by entity rot, not part rot -> 1 Core (the rotation fact only) C FromSetup discards the origin -> 1 Core + 2 App + 1 Content (the shipped defect, now caught in three projects) D drop entScale on BoundsCenter -> 2 App + 1 Content E landblock flat branch drops the centre -> 1 Core F landblock graph branch drops it -> 1 Core G drop partScale on the landblock centre -> 1 Core H re-apply the 10-cap to every branch -> 1 Core I remove the cylsphere cap -> 1 Core AP-152's own two sabotages re-run against this tree: the step-0 gate disabled still reddens exactly its five facts with Headless 89/89 green, and cylinder-first flooding still reddens exactly one. Clean Release build after deleting all 44 bin/obj: 0 errors, 21 pre-existing warnings. Complete suite 11,208 passed / 4 skipped / 0 failed, +5 on the 11,203 baseline at 4abd1b5e — Core 4264 -> 4268, Content 126 -> 127, App unchanged (one rename, not an addition). No new skips. NOT yet gated live. This moves shadow-cell membership for real objects, in both directions, and the connected session must look for both: props and doors that START blocking from a neighbouring cell (the 73 CylSphere+BSP Setups), AND ones that STOP blocking (the 99 Sphere+BSP Setups can shrink; 43 shrink below their pre-4abd1b5e size, which is the regression this fixes). Tall indoor props and door slabs — the ones whose sphere sits metres above the part origin — are where the change is largest. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-06 15:52:04 +02:00
Erik	4abd1b5eb7	fix(physics): AP-152 — dispatch collision shapes BSP-first, at emission and at the cell flood ... The register row predicted "catching or stopping on a doorway sill". That symptom could not have been occurring. `Transition.BspOnlyDispatch` (TransitionTypes.cs:1348, landed 2026-05-25 as A6.P7) already skipped both primitive branches (:3911, :3954) whenever the target's wire PhysicsState carries HAS_PHYSICS_BSP_PS, and ACE sets that bit from CSetup.HasPhysicsBSP for every affected Setup. The extra primitive was never tested for collision. The live defect was CELL MEMBERSHIP. The same shape list feeds `ShadowObjectRegistry.BuildFloodSpheres`, which had no such guard and preferred Cylinders over everything whenever any Cylinder existed — retail's SECOND priority applied ahead of its first. For the 73 CylSphere+BSP Setups acdream therefore flooded shadow cells from the cylinder and never from the slab: an object absent from cells it physically occupies, which is the #98 / #168 symptom class, not the door-collision class the row named. Retail, re-disassembled from the PDB-paired binary (v11.4186, CodeView GUID 9e847e2f-777c-4bd9-886c-22256bb87f32, check_exe_pdb.py MATCH) rather than taken from Binary Ninja, which drops flag tests: CPhysicsObj::FindObjCollisions @0x0050f050 0x0050f165 test dword [esi+0xa8], 0x10000 0x0050f16f je 0x50f1a2 ; clear -> primitive dispatch 0x0050f18d call 0x518180 ; CPartArray::FindObjCollisions 0x0050f19d jmp 0x50f2b0 ; UNCONDITIONAL, past BOTH primitive loops ; (CylSphere 0x50f1a2, Sphere 0x50f21d) 0x0050f1d6 jae 0x50f317 ; CylSphere loop exhausted -> RETURN 0x0050f22f je 0x50f31b ; zero Spheres -> RETURN seeded OK_TS CPhysicsObj::calc_cross_cells @0x00515230 0x00515285 test dword [esi+0xa8], 0x10000 0x0051528f jne 0x515305 -> CPhysicsObj::find_bbox_cell_list @0x00510fc0 0x005152d1 call 0x52b9f0 ; cylsphere branch, below the jump 0x005152fb call 0x52b990 ; sorting-sphere branch, below the jump Priority at both consumers: BSP -> CylSphere -> Sphere -> nothing. BSP wins. Every address above was resolved back to its symbol by exact lookup in named-retail/symbols.json. Changes: * `ShadowShapeBuilder.FromSetup` gains a step-0 dispatch gate. Steps 1 and 2 are skipped entirely when any part's EFFECTIVE GfxObj carries a physics BSP. The gate and step 3 now share one `EffectivePartGfxObjId` helper, so they cannot read different identities — a gate on `setup.Parts` would, after an ObjDesc swap, suppress the primitives while step 3 emitted nothing and `Build` returned null, deleting the entity's collision. Emission order is unchanged. This also removes acdream's undeclared reliance on the server sending the flag: the gate is derived from the parts, exactly as CPartArray::CacheHasPhysicsBSP @0x00518110 derives it. * `ShadowObjectRegistry.BuildFloodSpheres` now applies calc_cross_cells' own order: BSP, else Cylinder, else everything. Given the gate above this is a no-op for every shape list acdream produces (FromSetup is now exclusive; both landblock-static publishers already emit homogeneous lists), so the measured membership delta remains attributable to the gate alone. It is kept for the same reason BspOnlyDispatch is kept: retail genuinely dispatches here, and it guards a future additive producer. `Transition.BspOnlyDispatch` is deliberately untouched. Register: AP-152 RETIRED with its four false statements corrected — the risk statement (the symptom was already inert); "small and centred at the part origin" (max primitive is 6.714 m, and 0x0200086E's sphere origin is (0.759, 0.165, 5.842)); the cottage door's "~14 cm base Sphere" (it is 0.100 m; 0.141 is Setup.Radius, which AP-22 proved is never collision geometry); and naming one pinning test where two existed. AP-153/154/155 filed: retail's dispatch flag is cached once at InitPartArrayObject+0x7e where acdream's gate is live; the query-time guard takes a client-derived flag off the wire; and the static publishers emit Setup Spheres as height-capped Cylinders while BuildFloodSpheres approximates retail's bounding box with bounding spheres. Tests. Both pinning tests corrected, neither deleted: `FromSetup_DoorSetup_ProducesFourShapes` -> `..._EmitsBspPartsOnly`; `FromSetup_DoorSetup_SphereAtExpectedLocalOffset` re-hosted on `_ => false`, the DAT-real configuration for the 3,605 Sphere-only Setups. `FromSetup_ScaleFactor_MultipliesAllRadiiAndOffsets` was the campaign's eighth green test covering nothing — its assertions sat inside `if (CollisionType == Cylinder)` on a fixture with zero CylSpheres, so only `Scale == 2.0f` ever ran. Proved empirically: with the sphere radius scale deleted, the old body passes and the corrected body fails. Three new facts: the effective-identity gate, the App-layer CylSphere+BSP registration (no App fixture combined the two before), and the flood-set dispatch. One new installed-DAT sweep pins 172 affected Setups (73 CylSphere+BSP, 99 Sphere+BSP) behind external bucket controls, re-measured independently and agreeing exactly with the filing commit's separate sweep. All eight sabotages run and reported; every discriminating fact reddens in the intended direction and only there. Clean Release build after deleting every bin/obj: 0 errors. Complete suite 11,203 passed / 4 skipped / 0 failed, +5 on the 11,198 baseline at ec29a732 — exactly the five added facts, no new skips. Blast radius, corrected: the FromSetup half is graphical-only (its sole production caller is LiveEntityCollisionBuilder in AcDream.App, which AcDream.Headless cannot reference — Headless -> Runtime -> Core/Content). The BuildFloodSpheres half lives in AcDream.Core and DOES execute in Headless via LandblockPhysicsContentBuilder, but is behaviour-neutral there because both of that builder's registrations pass homogeneous lists. Headless suite green at 89/89. NOT yet gated live: this changes shadow-cell membership for 22 Setups used by 151 Door weenies and 38 stationary props. Needs a connected session. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-06 14:51:36 +02:00
Erik	7b3e2895cd	docs: close the AD-10 review findings — AD-65's magnitude was half the truth ... Both AD-10 review lenses PASS; the deletion stands. These are the findings they raised. One production file touched, comment-only. AD-65 WAS UNDERSTATED BY HALF, and it is the finding that matters. The row states the factor as cos^2(theta) and then quantified 1-cos(theta): "13% at 30 degrees, 29% at 45". The correct figures are 25% and 50%. This is not algebra alone — #331's probe in the same push measures 0.0735 m travelled for a 0.1 m request at 30.96 degrees, i.e. 26.5% short, which is exactly cos^2(30.96). AD-65 is a LEAD for #269's slope-slide residual; at the understated magnitude it reads as marginal and could have been dismissed. At 50% short at 45 degrees it is a serious candidate. I repeated the wrong figure in conversation before the review caught it. "VERBATIM/FAITHFUL PORT" of Transition.AdjustOffset was asserted in five places and was false as of the very next commit, which filed AD-65 and AD-66 against that same function. Corrected to "structurally exact, with exactly two filed divergences" in the register row and the production doc comment. RECORDED, and it favours the change: the redundancy measurement is CONTINGENT on AD-65 — the two mechanisms agree today partly because both under-travel downhill. That makes this deletion a PREREQUISITE for fixing AD-65 rather than merely compatible with it; had the projection survived, correcting AdjustOffset would have re-introduced a disagreement between two live projections. The record claimed no such thing and should have. UNTESTED AXIS recorded: the contract's T2 — its mandatory wrong-plane-versus- right-plane discriminator — was dropped without record, breaching the contract's own clause requiring exactly that to be written down. The consequence is precise: the deletion is measured, but the change's only claimed BENEFIT (a walkable non-terrain surface now gets the committed contact plane instead of terrain far below) has zero automated coverage and rests on source reasoning. Stated in the row rather than left implied. #331 SEVERITY RAISED from UNKNOWN — the discriminator is known and it is not the fixture. With `body: null` the same uphill sweep climbs (ok=True, moved (0, -0.0999, +0.060)); with a body supplied it returns ok=False and zero movement, under a call profile identical to the local player's (IsPlayer|EdgeSlide + the human two-sphere Setup). A diagonal request keeps cross-slope X and zeroes only up-slope Y, and it fires on a 1.1 degree ramp. So "confined to the synthetic fixture" is no longer the comfortable default: the failing call shape is the shape production uses. Nothing in the suite asserts uphill progress on a walkable slope, which is why it was invisible — the test that found it passed vacuously, because the body never moved. Also: malformed XML doc on ComposeOffset (duplicate </summary> swallowed the retirement note from tooling) fixed; the placement-cutover plan's item 5 and its stale "After C5" line now record AP-22 and AD-10 as retired. Core builds clean. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-06 10:08:53 +02:00
Erik	fb454b748c	docs(register): file the AdjustOffset snap_to_plane and safety-threshold divergences ... Both were found inside acdream's port of CTransition::adjust_offset while retiring AD-10, and neither had a register row — grep confirms no existing row mentions snap_to_plane, SnapToPlane, naturalResting, or away-plane. Filed as AD-65 and AD-66. Neither is fixed here: both change LOCAL-PLAYER movement feel and need their own visual gate, and folding them into the remote-movement change would have put a local-player regression behind the wrong acceptance test. AD-65 — the `collisionAngle > 0` arm substitutes `result -= N * angle` for retail's Plane::snap_to_plane call, making the if and else arms byte-identical. snap_to_plane (0x00509c50) writes only v.z and leaves XY alone, so acdream descends slopes 13% slow at 30 degrees and 29% slow at 45. Uphill is correct. Recorded as a LEAD for the open #269 slope-slide residual, explicitly not a diagnosis — the direction fits but nothing here establishes causation. #269's friction and jump chains are byte-exonerated and are not re-audited; adjust_offset is a different function. AD-66 — the safety push-out substitutes `radius * Normal.Z` for retail's bare `radius` in both the trigger and the zDist numerator, knowingly and with a written rationale. The rationale may be right; the missing row is the defect. The code comment's "ACE and the published pseudocode have the original threshold" understates the case — the retail binary has it. Both directions are byte-verified against the PDB-paired v11.4186 binary (GUID 9e847e2f-777c-4bd9-886c-22256bb87f32, check_exe_pdb.py MATCH), not inferred from pseudo-C: Binary Ninja renders every x87 comparison in this function as the fnstsw/test-ah mush and cannot be read for branch direction. AD-65's row records the exact three instructions and the FPU condition-code reasoning; AD-66's records the four operand loads showing neither site multiplies by N.z, plus both float constants read from the image (0x795344 = 0.0f, 0x7c6878 = 0.00019999999494757503f). AD-10's own retail anchor was corrected in the previous commit for the same reason: pc:272296-272346 truncated the sliding-normal validity gate at the head and the whole safety push-out block at the tail. No code change; no test change. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-06 09:36:41 +02:00
Erik	886333a2a9	refactor(physics): delete the redundant pre-sweep slope projection (AD-10 retired) ... Stage 0's measurement (previous commit) says the projection is redundant, so AD-10 retires by deletion rather than by narrowing. The measurement. With the sample forced to null at BOTH fork sites, from a clean build: * a remote running 30 ticks down a 31-degree walkable ramp produces a BIT-IDENTICAL trajectory, position for position; * on an 8.4-degree ramp the two differ by at most 2.8e-5 m in Z after 30 ticks (0.03 mm) and are identical in X and Y — float ordering noise from projecting twice against the same plane rather than once; * the whole AcDream.Runtime.Tests suite is unchanged. That is what redundancy looks like, and the arithmetic explains it. The boundary projection and Transition.AdjustOffset are the same operation (v -= N * dot(v, N)) against the same plane, and the composition is idempotent: a vector already on the plane has dot(v, N) == 0, so the sweep's own projection is a no-op on an already-projected offset and the full-strength projection on an unprojected one. Either alone produces the same offset. On terrain a THIRD mechanism, ValidateWalkable's push-out, re-seats the sphere on the plane every sub-step regardless. Deleted: * both RuntimeRemotePhysicsUpdater sample sites (the host and no-host fork branches carried the block verbatim — the AP-22 shape, a row naming one site where two exist); * the terrainNormal parameter and projection block on RemoteMotionCombiner.ComposeOffset; * the same block on ComputeOffset, which has no production callers but held a second copy of the divergence, so leaving it would have made the row's retirement false; * PhysicsEngine.SampleTerrainNormal, now callerless. Removing the parameter rather than passing null is deliberate: it is what makes a future one-site-only regression a compile error instead of a silent half-fix. Two tests went with it — ComputeOffset_RootMotionFallback_SlopedTerrainNormal_ProjectsZOntoSlope and its flat-ground twin. Both were weak on their own terms: they drove the production-dead ComputeOffset and computed their expected values by re-implementing the projection formula, so they could catch a wrong MULTIPLY but never a wrong PLANE — which is exactly what the divergence was. The surviving coverage is geometric and runs the production tick. Three claims in the old row did not survive contact with the code and are recorded in the retired row rather than quietly dropped: the justification (remotes do run the sweep); the description of ComposeOffset's guard as "interpolation-active" when the code reads `if (!interpolationOverwrote`; and the roof clause, stale since Bug B gated the sample on OnWalkable — a steep roof is OnWalkable == false, so the path never ran on #32's geometry. The retail anchor is corrected too: pc:272296-272346 truncated both the sliding-normal validity gate at the head and the entire safety push-out block at the tail. The whole function is 0x0050a370, pc:272271-272393. This does not fix #32 and does not partially fix it. #32's remote half was already closed at 204d0ae0. What deletion does improve is the case #32 never covered: a remote on a WALKABLE non-terrain surface — a bridge, a dock, a gentle roof, a ramp inside a building — where the terrain sample returned the plane of the ground far below and applied a wrong plane rather than none. That surface now gets the body's own committed contact plane, because that is the only projection left. The planning contract this work executed is committed alongside as docs/research/2026-08-06-ad10-contract.md. Release build 0 errors. Complete solution suite 11,196 passed / 4 skipped / 0 failed against the ef976c6d baseline of 11,195 / 4 / 0 — reconciled exactly as +3 new Runtime tests and -2 deleted Core tests. Visual gate outstanding: G1 (the ~5 Hz staircase on rolling terrain) is the veto criterion and runs first; then slope-descent smoothness, a walkable non-terrain surface, the #32 roof scenario, and flat ground. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-06 09:35:22 +02:00
Erik	ef976c6dbb	docs(register): correct AP-22's evidence claim (review follow-up) ... The register half of 619de97a, which was silently dropped — its heredoc invoked `python`, which does not exist on this box (`py` does), so the edit never ran while the commit still reported success. Worth noting as its own small lesson: a shell that fails inside a compound command can leave a commit claiming work it did not do. Content of the correction, from the AP-22 architecture review: the retirement commit's "Headless.Tests 89/89 exercises the site-3 copy" is false, disproved by sabotage — restoring the invented cylinder in both static sites left the whole suite green. Two of three deletions, including the headless-only one, rest on the installed-DAT reachability proof alone. Also recorded: sites 2/3 used the wider `Radius > 0f` guard (differing from site 1's over the DAT by exactly one Setup, 0x02001657, denormal radius 1.3e-39); the load-bearing fact is that all 1,652 no-primitive Setups carry Radius exactly 0; and retail's report_object_collision does read GetHeight for the quadrant field, which is not a refutation of the FindObjCollisions shape-dispatch claim. Reachability is now independently reproduced by four decoders plus tools/SetupInspect. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-06 08:55:23 +02:00
Erik	bc4679cda5	fix(physics): delete the invented Setup-radius collision cylinder (AP-22) ... Retail synthesizes NO shape for a shapeless object, so the fix is deletion, not a corrected height formula. CPhysicsObj::FindObjCollisions @0x0050f050 dispatches exclusively -- BSP xor CylSphere xor Sphere xor nothing. The BSP branch leaves via an unconditional `jmp 0x50f2b0` at 0x0050f19d and cannot reach the primitive branches; a CylSphere-bearing object that survives its loop returns rather than falling through to the Sphere loop; and with zero cylspheres, zero spheres and no physics BSP, `0x0050f22f je 0x50f31b` branches straight to the epilogue, returning the OK_TS seeded at `0x0050f13b mov edi,1`. CPartArray::GetRadius (0x005180a0) and GetHeight (0x005180b0) are absent from the function's entire call set -- Setup.Radius/Height serve attack cones, cylinder_distance and MoveTo, never collision geometry. Disassembled directly from the PDB-paired binary (GUID 9e847e2f-777c-4bd9-886c-22256bb87f32) rather than read from the Binary Ninja text, whose ebp_1 aliasing in this function is visibly corrupt. THREE copies were deleted, not one. The AP-22 register row cited LiveEntityCollisionBuilder.cs and ShadowShapeBuilder.cs; the latter never reads Setup.Radius at all, and the row omitted both LandblockPhysicsPublisher.PublishStaticEntity and LandblockPhysicsContentBuilder.PublishStaticCollision -- the second being the only copy the headless host executes. Fixing just the cited site would have left headless statics on the invented footprint. The branch was unreachable dead code, not a live approximation. A sweep of all 5,935 Setups in the installed client_portal.dat -- validated by byte accounting (5,935/5,935 records consumed with an exact 20 + 48*numLights residual tail, zero unexplained bytes) and independently reproduced by the production FlatCollisionAssetBuilder.FlattenSetup path -- finds 0 Setups satisfying the guard: every Setup with Radius > 0.0001 carries at least one CylSphere or Sphere, and all 1,294 genuinely shapeless Setups have Radius exactly 0. Buckets: 678 cylsphere, 3,605 sphere-only, 358 BSP-only, 1,294 shapeless, 4,282 with Radius > 0.0001. Nothing loses collision because nothing gained it, so no visual gate is required. Tests, all sabotage-verified in both directions: - InstalledSetupCollisionReachabilityTests (new, Content) -- the negative claim plus five EXTERNAL positive controls, so a broken enumeration cannot satisfy it vacuously. Inverting the claim reddens it; emptying the enumeration fails on the controls at 0 != 5935 rather than passing. - ShapelessSetupWithRadius_ProducesNoRegistration (new, App) -- restoring the deleted block reddens exactly this fact and nothing else. - Build_PropagatesExactStateFlagsScaleAndFullSeedCell -- re-hosts the state / PWD-flag / seed-cell coverage that rode on the deleted fallback test, whose fixture (a Setup with a radius and no primitives) cannot exist in the DAT. Flipping a FromPwdBitfield bit reddens it; so does swapping SeedCellId for the landblock id. Also corrects ShadowShapeBuilder's retail-anchor comment, which claimed each part's find_obj_collisions tests "CylSpheres + GfxObj BSP". CPhysicsPart::find_obj_collisions @0x0050d8d0 tests ONLY the GfxObj physics BSP; CylSpheres are a Setup-level array reached via CPartArray::GetCylsphere. That comment was the written justification for the additive emission now filed as AP-152, so it is corrected here even though AP-152 is not fixed here. AP-22 retired with evidence; AP-152 filed (live path emits primitives AND BSP parts additively where retail is exclusive -- 172 of 5,935 Setups including BSP doors; deliberately not folded in, it needs its own visual gate). Issue #330 filed: the headless host registers no live-entity collision at all, a pre-existing gap this survey established and nothing tracked. Gates: Release build 0 errors / 0 warnings. Complete solution suite 11,195 passed / 4 skipped / 0 failed (baseline 11,193/4/0 at bcb66ccd; +1 App for the added fact, +1 Content for the reachability test; the replaced test is net zero). No new skips. Headless.Tests 89/89 exercises the site-3 copy. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-06 08:27:26 +02:00
Erik	bcb66ccdf3	fix(test): cover the atlas-tier seam the D-1 fix depends on; correct AP-150's citation ... Both items come from the D-1 fix review (both lenses PASS, D-1 genuinely closed). No production behaviour changes. L1 — THE SEAM HAD NO COVERAGE. The D-1 fix's "empty by construction" claim rests on LandblockSpawnAdapter's atlas-tier filter (`if (entity.ServerGuid != 0) continue;`) skipping the live server projections DetachNearLayer deliberately RETAINS across a demote. The reviewer removed that filter and all 4,170 App tests passed — only two Core unit tests caught it, none through a demote. So the invariant the re-assert depends on could have been deleted silently, re-opening D-1 by another route: a non-empty re-assert whose mesh reference is never satisfied leaves IsRenderReady false, which is the portal hang again. NearToFarDemote_WithALiveServerEntity_StaysRenderReady now demotes a landblock that CARRIES a live server-spawned entity through the real GpuWorldState + LandblockSpawnAdapter + LandblockPresentationPipeline, and asserts the retained entity never enters the desired set. Sabotage-verified: with the filter removed, exactly one test fails — this one — and the other 25 pass, including all four D-1 regression tests. That is the finding restated as a measurement: the D-1 tests genuinely do not cover this seam, and now something does. AP-150 citation corrected: the row cited 0x004D7064 as the ECM_UI::SendNotice_DisplayStringInfo call site. That address is the PStringBase construction of the "In Portal Space - Please Wait..." literal (:219516); the actual call is 0x004D70A1 (-> 0x006925B0). Same class of slip the #280 commit had just corrected for #326 — worth noting that a row filed WITH a byte-level disassembly still mis-cited a neighbouring address. Also refactored the existing pipeline demote test to keep its doc comment attached to its own method (an earlier insertion had orphaned its [Fact]). App.Tests 4,170 -> 4,171 passed / 3 skipped, net +1 for the new test. No new skips; none of #302/#308/#321 surfaced. src/ is byte-unchanged (the sabotage was reverted and verified). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-06 07:54:03 +02:00
Erik	43cfdc4a40	docs: accept #309 as a standing divergence rather than a planned fix (AP-136) ... User decision 2026-08-06. #309 moves from OPEN to DEFERRED/ACCEPTED, and AP-136 becomes its permanent record rather than a staging note. No code changes. No new register row was filed: AP-136 already carries the full retail mechanism (SetPositionInternal 0x00515BD0 -> store_position 0x00515CE2 -> GotoLostCell 0x00515CF2, removed only by InitObjCell 0x00508260 -> reenter_visibility 0x00516250), the exact divergence, and the observable. Filing a second row would have duplicated it. WHY DEFERRED, recorded so a successor does not silently re-litigate it. The retail-faithful end state is a park that SURVIVES cancellation. That was implemented and reverted this round, because it costs (a) reversing a deliberate shipped invariant — NewerPositionPickupAndParentEachCancelExactLostOperation asserts that a newer Position cancels the park — and (b) GameRuntime teardown convergence (stage 10), where surviving parks never converge on shutdown. The observable requires a remote to teleport into a non-resident landblock AND then stop moving; ACE stops broadcasting for a stationary entity, while the ordinary 5-10 Hz case is superseded within ~150 ms. Revisit if teardown convergence is done for another reason, or if the observable is reported in ordinary play. CAUGHT WHILE RECORDING IT: deferring the fix does NOT cancel AP-136's six-step connected check. That check validates the SHIPPED rollback path (#312 / restorableOnCancel, which sits in SubmitPreparedPlacementCore — the shared core behind every production placement), not the deferred fix. It still needs running with ACDREAM_PROBE_PARK=1, and therefore must run BEFORE C5c's probe strip retires that flag. Both documents now say so; without that note the strip would have silently removed the instrumentation a still-owed gate depends on. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-06 07:49:20 +02:00
Erik	73cdb95c7b	fix(streaming): make a demoted landblock render-ready like a published one (#280 D-1) ... Both #280 review lenses returned FAIL on the same defect, and both were right. IsRenderNeighborhoodResident's widened outer arm requires IsRenderReady out to FarRadius, justified by "a Far-tier landblock registers with an empty mesh set and is therefore render-ready." That held only for a landblock that ARRIVED as Far. The second, equally first-class way to be Far tier is a Near->Far DEMOTE: DemoteLandblock -> EnqueueNearLayerRetirement -> LandblockRetirementStage.MeshReferences -> GpuWorldState.ReleaseLandblockMeshReferences -> LandblockSpawnAdapter.OnLandblockUnloaded => WantsLoaded = false while DetachNearLayer deliberately keeps the landblock loaded, terrain-mesh resident, terrain-collision resident and DRAWN. Nothing re-publishes an already-loaded landblock, so the demoted member satisfied NEITHER arm of the gate, permanently: wormhole tunnel plus centered "In Portal Space - Please Wait..." forever, no recovery short of relog. Reachable by ordinary play. Two consecutive recalls to the same landblock with walking in between makes ChangesStreamingCenter false, so there is no origin recenter and the region recentres through the ordinary demote diff. Also reachable via a mid-hold quality-preset drop -- ironically the exact scenario ReconcileDestinationReservationRadius was added to support. The pre-#280 radius-1 gate never touched that band, because nothing inside the Near ring can demote. FIX SHAPE. Make the two routes genuinely equivalent rather than teaching the predicate to tolerate the difference. ReleaseLandblockMeshReferences becomes "reconcile the registration to the post-retirement tier": after the release converges, if the landblock is still loaded AND still Far tier, re-assert the empty registration -- the identical OnLandblockLoaded(lb, empty) a PublicationKind.Far activation makes. It is empty by construction: DetachNearLayer retains only live server projections, which the adapter's atlas-tier filter skips. A full retirement is unaffected (DetachLandblock clears both _loaded and _tierByLandblock), and a throwing release still retries because the re-assert is only reached after the adapter converged. The alternative -- "|| (IsFarTier && IsLoaded)" at the gate -- was rejected: it fixes one caller while leaving IsRenderReady meaning two different things, which is precisely how this defect arose. After this change the predicate reads "drawable at its current tier" for every caller, with no knowledge of how the landblock got there. WHY THE TESTS MISSED IT, fixed here too: - Proof obligation P2 was discharged against RESIDENCY (the FarRadius+2 eviction threshold) rather than against IsRenderReady, the gate's actual atom. The contract now carries the correction and the restated obligation: no transition may REVOKE IsRenderReady from a landblock that stays inside FarRadius. - WorldRevealDerivedWindowIntegrationTests advertised itself as end-to-end against the real GpuWorldState but constructed it with no spawn adapter, so its IsRenderReady degenerated to IsLoaded via the "?? true". The single most load-bearing predicate in the change was stubbed out by a null in the test named after it -- the same shape as C5b's D3 and #276's three settler tests. Every fixture in that file now owns a real LandblockSpawnAdapter. - The P1 test's comment described its subject as "a Near-shaped completion the streaming window has since DEMOTED to Far". It is not; it is a fresh PublishAsFar, the case that does hold. Corrected, since a future reader would have taken it as demote coverage. Four new regression tests, all driving the real GpuWorldState + LandblockSpawnAdapter + LandblockPresentationPipeline through an actual demote, and all sabotage-verified in both directions (fail with the production change reverted, pass with it): NearToFarDemote_LeavesTheLandblockRenderReadyThroughTheRealPipeline NearToFarDemote_LeavesTheLandblockRenderReadyUnderBudgetedRetirement TieredWindow_StaysResidentAfterAnOuterRingDemote OutdoorReveal_SurvivesAnOuterRingDemoteDuringTheHold The budgeted variant exists because production composes LandblockRetirementCoordinator.CreateBudgeted, whose MeshReferences stage is a separate call site from the legacy pipeline's. SECONDARY, same commit: - R-1: ACDREAM_PROBE_REVEAL_RADIUS=0 was parser-accepted and Runtime-rejected -- it yields far = 0 for an outdoor destination, which fails invalid-readiness-shape on every acknowledgement, hanging the very A/B route the probe exists to measure. Parser floor raised to 1, with a 7-case table test. - R-2: the composite-warmup TRIGGER had silently moved onto the far window's critical path. Pre-#280 the gate and the composite domain were the same radius-1 square; #280 widened the gate without widening the domain, so every composite upload serialised behind the last outer-ring landblock for no readiness benefit. Warmup now starts once the NEAR sub-window is published -- trigger scope == domain scope, as before. The reveal gate is untouched: Evaluate still requires the full window AND composite readiness. - AP-150 filed: acdream's RetailWaitCueDelay = 5 s arming is NOT retail's trigger, and #280's commit message got this wrong on both clauses. Retail emits the notice unconditionally per tunnel rotation segment, in the else arm of the segment-expiry test at 0x004D6FCD; segment duration is RandDouble(0.6, 1.8) s, byte-decoded at 0x004D6FE6. The 5.0 constant at VA 0x007991B0 is CellManager::CheckPrefetchStatus's prefetch RETRY cadence and has nothing to do with the cue. acdream's own 0.6/1.8 segment constants already match retail exactly; only the arming is wrong. Adopting retail's unconditional emit is filed as #329 rather than folded in here -- it is a user-visible presentation change and wants the user's eyes. - AP-151 filed: the gate is materially STRICTER than retail on the mesh-build/GPU-upload axis. Retail's LScape::PreFetchCells blocks on DAT RESIDENCY only -- no geometry construction, no upload; that work is lazy at draw. acdream requires a DAT read, terrain mesh build, render-thread upload, spatial commit, collision admission and spawn-adapter activation per member of a 625-member window, metered at MaxCompletionsPerFrame. Nothing bounds the hold. This is the OPPOSITE asymmetry from AP-149; both are live at once, on different axes. - AD-2's amendment stated the false Far-tier readiness assumption verbatim; corrected, along with the same error in claude-memory/reference_two_tier_streaming.md, which now carries an explicit DO-NOT-RETRY on the special-case-the-predicate shape. - AP-115 scope-noted (it covers the cue's presentation, not its arming). - #326's SmartBox::set_mid_radius citation corrected: the entry is 0x00453180; 0x004531D0 is the mid-function re-arm branch. Blast radius: GpuWorldState, LandblockSpawnAdapter, WorldRevealReadinessBarrier and StreamingDiagnostics are all App-internal; AcDream.Headless and AcDream.Runtime reference none of them outside comments. Headless tests run green as part of the gate below, per C5b's lesson about surveys that skip the no-window host. Gates: Release build 0 errors, 18 pre-existing xUnit analyzer warnings. Complete suite "dotnet test AcDream.slnx -c Release -m:1" with ACDREAM_PAK_PATH set: 11,192 passed / 4 skipped / 0 failed, from a clean rebuild (a prior session's deleted probe file had been compiled into a stale test DLL). Baseline at fafc0b65 was 11,179 / 4 / 0; the +13 delta reconciles exactly to this commit's additions -- 3 readiness tests, 1 integration test, 7 parser table cases, 2 warmup-trigger tests. None of the known flakes #302/#308/#321 surfaced, and none is conflated with the finding above. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-06 07:27:28 +02:00
Erik	3aab05b0cc	fix(streaming): derive the portal reveal window from the live streaming radii (#280) ... The user watched far terrain visibly assemble after portal space exits. The reveal gate was NOT missing a hold — Slice E's hold mechanism is correct and already in place. The hold was measuring the wrong domain: it opened at a hardcoded 3x3 landblock neighbourhood (~192 m) while the visible world extends to the fog end (~2,189 m at the shipped High preset, inside a 2,304 m Far window). An 11.4:1 ratio. Retail's equivalent ratio is 1:1 BY CONSTRUCTION. `LScape` owns one `mid_width x mid_width` array of `CLandBlock*` (`LScape::SetMidRadius` @0x00504C00, `LScape::update_block` @0x005063A0), `mid_radius` is assigned directly from the user's `Render.LandscapeDrawDistance` preference (`SmartBox::SetRegion` @0x004531F0; values `Render_LandscapeDrawDistance_Values` @0x007CA988 = {3,5,8,11,15,25}, default 8 — both byte-verified against the PDB-paired 2013 binary), and that same square is simultaneously the prefetched set (`LScape::PreFetchCells` @0x00505660), the drawn set (`block_draw_list` over the same array), and the set the simulation blocks on (`CellManager::blocking_for_cells`). There is no retail configuration in which the client streams farther than it gates, because there is only one number. So the fix derives rather than duplicates. Four coupled parts, which is why this is one commit and not four — D1 without D2 hangs the client and D2 without D1 is dead code: D1 `WorldRevealReadinessBarrier` takes a live `Func<StreamingRevealWindow>` and stops being static: outdoor requires `FarRadius`, indoor still 0 (retail's `CEnvCell::PreFetchCells` @0x0052D1E0 arm). Read per evaluation, never captured — the radii are runtime mutable through Settings, and retail's answer to a mid-hold radius change is to reset, re-radius, and re-arm the blocking prefetch at the NEW value (`SmartBox::set_mid_radius` @0x00453180). `OutdoorNeighborhoodRadius` is deleted; there is no constant left to drift. D2 `StreamingController.IsRenderNeighborhoodResident` becomes tiered, because acdream's loaded landscape is: inside `NearRadius`, `IsNearTier && IsRenderReady`; out to `FarRadius`, `IsRenderReady` only. Without this the fix cannot work at all — nothing outside the Near ring is ever promoted, so any radius above `NearRadius` was unsatisfiable and would have held the reveal forever. Proof obligation P1 (a Far-tier landblock genuinely satisfies `IsRenderReady`) is now a test driven through the real `PublicationKind.Far` pipeline against a real `LandblockSpawnAdapter`, not an inference. D7 `RuntimeWorldTransitState.AcknowledgeDestinationReadiness` re-derived `indoor ? 0 : 1` and failed `invalid-readiness-shape` on any other value, so changing the radius alone would have looked like "the fix hangs the client". It is now a SHAPE invariant (`indoor => 0`, `outdoor => >= 1`). Runtime does not own the graphical host's streaming configuration and must not learn it; plumbing App radii into Runtime to preserve the strict equality is exactly the assert-a-mechanism-that-does- not-exist failure C5b was built to stop. Both non-graphical producers keep emitting their centre-ring token and stay legal, annotated in place. D6 `PhysicsEngine.IsNeighborhoodTerrainResident` rebuilt a full-map `HashSet` on every call, every frame of every hold. At radius 1 that was invisible; at radius 12 (625 ring members) it violates Slice I1's 0 B/resolve standard. Now an engine-owned scratch set, cleared in place; measured at 0 bytes over 1,000 warmed radius-12 queries. Also: the destination reservation opens at exactly the gate's radius and reopens on the same generation when the radius changes mid-hold (retail has one square for both, and no concept of prioritising an inner ring differently). Composite warmup deliberately stays `NearRadius`-scoped — the composite domain is entity-scoped and Far builds carry no entities, so widening it would walk the outer window to warm nothing. `ACDREAM_PROBE_REVEAL_RADIUS` is a measurement probe in a diagnostic owner (CLAUDE.md rule 5) so the connected route can be run A/B on one binary; it is NOT a user-facing prefetch knob, since a low setting would reintroduce the decoupling this slice exists to close. Register: AD-2 amended with the derived window, the two-tier split, and the four new retail anchors. AP-149 FILED for the residual this does not close — the outer ring accepts terrain-only publication where retail requires LandBlockInfo and every building EnvCell, so a distant building can still pop in at Far-ring distances. Do not let a later closeout claim parity. Docs: `ACDREAM_STREAM_RADIUS`'s CLAUDE.md description was wrong on every clause (the default is unset, not 2; it forces `NearRadius`; it is silently discarded by any Settings save) — corrected, since that is the file every session reads. `reference_two_tier_streaming.md` corrected in four ways, including "Far tier = terrain only": Far also publishes terrain COLLISION, which is precisely what makes this fix viable. #280's issue text had the right conclusion from a wrong premise (it names a view-distance setting acdream does not have) — corrected, and the missing Viewing Distance option filed separately as #326, with #327 (DDD progress readout) and #328 (hardcoded 5000 f far plane vs retail's byte-verified 4000) filed alongside. Expect LONGER holds and the "In Portal Space - Please Wait..." cue on recalls MORE often. That is convergence toward retail, not away from it: retail emits the byte-identical string for the whole duration of a blocked prefetch and polls at 5 s intervals. The failure condition is non-convergence, not duration. Gates: Release build 0 errors. Complete suite 11,178 passed / 4 skipped / 0 failed, against a re-measured 11,142 / 4 / 0 baseline at 9ee9c1a1 — +36, reconciled exactly as 36 new tests (App +23, Runtime +10, Core +3), zero deleted, zero newly skipped. Nine discriminating tests sabotage-verified in both directions. The connected/visual gate is batched into C5's matrix; its recipe, its three positive artifacts, and its required recall leg are written into the campaign plan. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-05 23:54:59 +02:00
Erik	9ee9c1a1a6	fix(runtime): close the C5b re-review findings — Gate A narrowing filed, no-window payload gate, bisect hazard recorded ... Both C5b re-reviews returned PASS on 02578441..ff100cf3. This lands the bookkeeping corrections they left, the one gate asymmetry both found independently, and one wrong retail fact neither of them caught. 1. AP-148 / #325 — Gate A's teleport test, wrong on primary source twice. The C5b contract stated retail's Gate A teleport term as "TELEPORT_TS equal" (and, in the trace block, as "must NOT be newer") and blessed acdream's `teleport == _timestamps[Teleport]` as retail-exact. Disassembly of the PDB-paired binary at SmartBox::HandleReceivedPosition 0x0045402B-0x00454054 says otherwise: the shortcut is taken iff the wire stamp is equal OR newer (wrap-safe) — `sbb eax,eax / neg eax` materialises the carry of the compare and the branch skips Gate A on CF, i.e. only when the wire stamp is strictly OLDER. It is CPhysicsObj::newer_event @0x00451B10's identical idiom with the operands swapped. Binary Ninja drops the flag test and renders it `if (-((eax_7 - eax_7)) == 0)`, always true — which is why two rounds of reading pseudo-C recorded it backwards. So acdream's ForcePosition disposition is a strict SUBSET of retail's Gate A set, and a local ForcePosition carrying a newer teleport stamp is misrouted into a full Apply: wire heading instead of preserved heading, unparent, possible placement frame, zeroed velocity, TELEPORT_TS advanced, and OfferTeleportDestination called for a packet retail never starts presentation for. PhysicsTimestampGate.cs is NOT changed. The predicate exists twice (also ValidAcceptedAuthority's PreviousTeleport == AcceptedTeleport), and the fix has to decide TELEPORT_TS's disposition on a Gate A path that has never seen a stale-but-equal pair. #325 records all of it and says explicitly that it is not a one-line comparison swap. C5b made this marginally better, not worse: clearParent was unconditionally true before C5b and is unchanged; installPlacementFrame moved toward retail's HasAnims gate. 2. Retail F2 / architecture L-A — the no-window route had no pre-merge payload validation. Root fix, not a documented asymmetry. The graphical route validates before the merge (OnPosition's payloadIsValid -> LiveEntityInboundAuthorityGate's !payloadIsValid return); despite its name CanAcceptPositionPayload is not projectile-scoped. The no-window route had no equivalent, and since D1 fed an unvalidated LandblockId into CommitWireCellRebucket — where 0 is the withdrawal shape, silently de-residencing the entity in the field every bot reads as CellId. RuntimeLiveEntitySessionController.OnPositionUpdated now applies the same rule at the same point, reusing RuntimeAuthoritativePositionRouteClassifier.IsValidCreateWirePosition plus the finite-velocity term — the exact pair TryApplyPosition already applies on its initial-residence branch. Chosen over documenting it because the fix is five lines and leaving it would have left two written claims falsified by the code. It is a behaviour change: headless now drops packets it merged. Against ACE the set is empty, and the graphical host has carried this gate since it was written; the argument is recorded in the contract's §15.2 rather than gated. Two test fixtures carried cell ids retail's own inbound_valid_cellid rejects (low words 0x41 and 0x51, above the 0x40 landcell ceiling). Their constants were corrected; their assertions were not. New test sabotage-verified in both directions: gate removed -> red at the withdrawal-shape assertion; gate moved to guard only the cell commit -> red at the pose assertion, which is what makes it a before-the-MERGE test rather than a before-the-commit test. 3. Register and doc corrections. - AD-64: "deliberately absent" was presented as the complete difference list and was not. Adds (a) the residence gate is weaker than the merge's own — both hosts' commits use TryGetCurrent while TryApplyPosition's FIFO branch uses TryGetTransaction, so the wire cell can commit ahead of the continuation that will replay it; (b) the two missile gates are two different expressions that agree today; (c) the payload gate, now present. Risk column records that (a) and (b) have no discriminating test on either side. - AP-147: amended for D1 — pre-D1 the no-window host published [Updated] alone and lost the Rebucketed, so a headless event log is now a real instance of the "consumer that snapshots a delta" the row warns about. - AD-60: "Matches retail exactly" scoped to the withhold, since the row's body documents two channels that do not. - CommitWireCellRebucket: notes the unreachable ThrowIfNull / EnsureNotDisposed precedence inversion. - TryCommitAcceptedWireCell: the discarded commit bool is explained rather than left bare — false means IsCurrent went stale, unreachable three statements after a synchronous TryGetActive. 4. Bisect hazard recorded in the C4 closeout handoff (the doc CLAUDE.md sends readers to before any C5 work) and in the contract's §15.3: commits 735f0a72..23aa62f2 contain a live headless defect — every remote's FullCellId frozen for the session — introduced by 735f0a72 and fixed only at ff100cf3. Nothing throws and no test in the range fails. Gates: Release build 0 errors/0 warnings. Complete suite 11,142 passed / 4 skipped / 0 failed against the 11,141 / 4 / 0 baseline — net +1, exactly the one new test. No flake appeared (#302, #308, #321 all green). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-05 23:10:24 +02:00
Erik	ff100cf33f	fix(runtime): give the no-window host a post-merge canonical cell commit (D1, AD-60/AD-64, AP-146/#320) ... C5b (735f0a72) made the steady-state accepted-Position merge stop writing residency. That is retail-correct — HandleReceivedPosition @0x00453FD0 reads the wire objcell_id into a local and never assigns the object's cell — and it stays. What C5b did not account for is that its replacement writers both live in AcDream.App: the OnPosition prologue rebucket (AD-60's W2) and the post-routing wire-cell adopt (W3, AP-135). The two hosts run parallel, non-shared inbound routes. LiveEntitySessionController -> LiveEntityNetworkUpdateController.OnPosition is graphical-only; RuntimeLiveEntitySessionController.OnPositionUpdated is the no-window route and is constructed only at HeadlessSessionHost.cs:682. So AcDream.Headless had NO post-merge cell writer at all. Every remote's FullCellId was written at create/placement and then frozen for the session — and RuntimeEntityObjectViews .Snapshot projects exactly that field as RuntimeEntitySnapshot.CellId, i.e. every bot's entire world view. The local player lost one of AP-146's three refresh edges, which matters beyond cosmetics: RuntimeSetPositionState .IsAffectedCollisionResident reads FullCellId to pick which bodies a landblock retirement parks, so a bot running A->B without teleporting would have retired A while parking a body physically in B. The fix, in three parts: 1. RuntimeEntityObjectLifetime.CommitWireCellRebucket — a new Runtime owner for the committed VALUE, extracted verbatim from LiveEntityRuntime .RebucketLiveEntity. This is also the root-cause fix for the layering inversion the review found: AD-60 was documenting its own correctness by naming an App class the Runtime assembly cannot reference. Behaviour on the graphical side is unchanged — record.FullCellId is a proxy for record.Canonical.FullCellId, which is the record the callee reads, and the commit is still CommitRebucket. Verified load-bearing for BOTH hosts: sabotaging the preserve branch reddens the graphical LiveEntityRuntimeTests.CanonicalOnlyRebucket_DoesNotOverwriteAuthoritativeFullCell as well as the new headless assertion. 2. RuntimeLiveEntitySessionController.TryCommitAcceptedWireCell — the no-window W2, under the same reachability rules the graphical route applies: Rejected writes nothing (the shape the App authority gate produces by returning false); a bound-projectile packet writes nothing (routed by the graphical host through the canonical projectile placement owner, which returns before W2); an active initial-create residence writes nothing (RebucketLiveEntity's own early return — while the lease is live the SetPosition conductor is the sole cell authority); a local ForcePosition writes only when the accepted-Position drive declined it (NotApplicable), because a handled force is placement-receipt-authoritative. W2/W3 themselves are untouched. 3. On the committed value (the landblock-vs-cell trap). RebucketLiveEntity's preserve branch fires on a LANDBLOCK-shaped id — low 16 bits 0xFFFF — and exists for LocalPlayerProjectionController.Project, the per-frame local movement caller that emits exactly that shape. An inbound wire objcell_id is never landblock-shaped, so on the accepted-Position route the branch is not taken and the exact wire cell is committed. That is what W2 commits today and what this now commits; the no-window host has no per-frame caller at all. Ordering is matched, not improved on: the force drive submits its placement before the commit, so its first submit still reads the pre-commit FullCellId — AP-138's amended route-2 CurrentCellId measurement. Bookkeeping in this commit: - AD-60 corrected. Its surviving-channel enumeration presented "the local force path, the missile arm" as exhaustive; the entire no-window host belonged in it. 23aa62f2's W2/W3-redundancy measurement is preserved verbatim. - AP-146 and #320 amended the same way — their three-edge list was written from the graphical host and silently assumed both hosts shared it. The no-window host had two of three; it now has all three. - AD-64 filed: the reachability decision is now expressed once per host. The value is single-sourced; the gate set is not. - #324 filed: unifying the two session controllers is the genuinely correct fix and is campaign-sized (presentation recovery, hydration, the equipped-child renderer, and the remote/projectile routing arms only one host has). Not attempted here, per the fix brief. Gates. Release build 0 errors. Complete suite 11,141 passed / 4 skipped / 0 failed, against the 11,134 / 4 / 0 baseline at 23aa62f2 — net +7, exactly the 7 tests added. Eight sabotages verified, each red on at least one discriminating test and green when reverted: remote commit removed (2 Runtime + the end-to-end Headless test); local ordinary commit removed; local NotApplicable-force commit removed; force commit made unconditional; residence gate removed; missile gate removed; Rejected gate removed; preserve branch broken (red on both hosts). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-05 22:36:31 +02:00
Erik	23aa62f292	fix(review): close the C5b architecture-review findings (D2/D3/D4, L1-L5, S1) ... Follow-up to C5b (735f0a72). The retail-conformance review passed, so no production behaviour line moved: the flag truth table and the refreshPosition:false withhold are untouched. This is blast radius, test discrimination and documentation fidelity - plus two findings I could not confirm and am rebutting rather than complying with. D3 - THE PUBLISH-CONSERVATION TEST DID NOT DISCRIMINATE. The reviewer was right and it was the worst finding here: proof obligation 3's test passed identically with C5b reverted. Its only delta assertion FILTERED (Assert.Single(deltas, Rebucketed && parentGuid)), so the pre-C5b stream [Rebucketed] and the post-C5b stream [Updated, Rebucketed] both satisfied it, and childSpatialBefore+1 held in both worlds because whichever site did not move the cell propagated idempotently. It now asserts the complete ordered parent stream plus each element's CellId and Position.ObjCellId. Sabotage: restoring refreshPosition:acceptedPosition turns it red (it was green before), together with the withhold test and the new L5 test. That cardinality change was itself unfiled and is now AP-147: a cell-changing accepted Position publishes TWO entity deltas where it published one, and the intermediate Updated pairs the OLD CellId with the NEW wire Position - a torn pair that did not exist pre-C5b, since both halves used to move inside one publish. No production consumer reads a delta's paired fields, but a recorder/plugin/bot event log would capture it. The row states why suppressing the Updated is not available at that layer (the merge cannot know whether its caller reaches W2). D4 - THE PROJECTILE DOC COMMENT WAS FALSE AND ITS RETAIL ARGUMENT WAS INVERTED. SyncPresentationFromResolvedBody claimed record.FullCellId is "the WIRE cell ... stamped by the merge's RefreshDerivedState/SetFullCell, before classification ever runs" and argued from retail's store_position @0x00515CE2 that the destination cell is the right one. C5b falsified the premise; the missile arm also returns before W2, so nothing stamps the wire cell for a projectile at all. Rewritten. The honest conclusion, which the old text would have called wrong: on a stored outcome presentation now pairs the DESTINATION world position with the SOURCE cell. That is not a choice this method can make differently - StoreAcceptedDestinationPose writes only Position/Orientation, so record.FullCellId and body.CellPosition.ObjCellId now hold the same source cell and reading either yields the same value. The divergence is AP-138 item (1)'s store-writes-pose-but-not-cell residual, retiring via #309, not a field choice here. Projecting the wire cell instead would invent a residency the placement declined - the AP-1 shape C5b closed. L3/L4/L5 - PINNING GAPS, ALL THREE CONFIRMED AND CLOSED. L3: the matrix's oracle passed HasAnimations as a literal, so the merge's old.MotionTableId ?? old.Physics?.MotionTableId and RuntimeAcceptedPositionRouteRequests.Build's canonical-snapshot twin were textually identical and pinned by nothing. The oracle is now BUILT by the production constructor. L4: every fixture set both MotionTableId halves to the same value, so deleting either operand of the ?? was undetectable while the production comment said the mixed case is the real-world one. Six mixed rows added, including the explicit-zero row (a present-but-zero top half is not null, so ?? never reaches the physics half). L5: the retained Rebucketed ternary had zero coverage through TryApplyPosition - every restoreCancelledPark test called Forget directly. Now driven through the real merge, with the wire cell deliberately the SOURCE while the park's committed body cell is the DESTINATION, so the restored residency can only have come from the rollback. Sabotage (each red, each restored): merge ?? -> top half only, 1 red; -> physics half only, 2 red; Build's ?? -> physics half only, 2 red; ternary -> constant Updated, exactly the L5 test red. L1/L2 - THE MISSING TEST IS ADDED; THE DEFECT IS NOT THERE. The reviewer was right that C5b's "no fixture covers pickup at that layer" was inaccurate - LiveEntityNetworkOnPositionCollapseMatrixTests drives the real OnPosition at ~26 sites - and the end-to-end test is added: withdraw -> accepted Position -> IsSpatiallyProjected && FullCellId == wireCell, both guid classes. But ChildUnparentDisposition.Pending is NOT a live defect, because it is production-unreachable. The sole production _withdrawProjection binding (LivePresentationComposition.cs:599) is LiveEntityProjectionWithdrawalController.WithdrawExact, whose only Pending mint is inside its catch block and therefore always carries a non-null Failure - and AdvanceUnparentTransition rethrows at EquippedChildRenderController.cs:1307 BEFORE the return Pending at :1309. The named drop scenario does not reach it anyway (BeginDetachedRemoval has already emptied the capture list) and would be correct if it did: a previously-equipped child is LegacyImmediate, so the FullCellId != 0u gate at DatLiveEntityProjectionMaterializer.cs:767 is never consulted and re-projection uses the wire cell at LiveEntityRuntime.cs:824. Measured while building that test, and NOT what C5b assumed: W2 and W3 are REDUNDANT on the remote tail. Sabotaging W2 alone - adopting the committed cell instead of the wire cell, OR skipping the rebucket outright - leaves the whole file green, because W3's RemoteMotion.CellId write reads through to canonical FullCellId via CommitCanonicalCell, whose CellCommitted recovery re-installs the bucket. Only removing BOTH goes red, and then the new test is the only red in the file. So it is named for what it pins, and AD-60 is amended with the measurement: neither channel is individually load-bearing, so a future retirement of one is caught by nothing else. D2 - REBUTTED, WITH THE REAL GAP FILED INSTEAD. The reviewer's hypothesis was that TryApplyInitialCreateCompletionPresentation's staleness guard lost its ability to detect an intervening steady-state Position when C5b stopped the merge stamping the wire cell, and asked for a PositionAuthorityVersion term. I do not think that is right and did not add it. The receipt's facts are the canonical BODY's pose and cell at publish (PublishExecutorCompletion builds both from the record). Exactly two owners can move them: a Runtime SetPosition commit/withdrawal, every one of which calls AdvancePlacementCommit - the only caller family is RuntimeSetPositionState - and a rebucket, which moves FullCellId. Both are already covered by the two existing terms. An accepted steady-state Position is neither, and C5b did not make it one: the merge refreshes the snapshot and advances PositionAuthorityVersion but never wrote the body, and the App generic tail writes the RENDER entity. The wire-cell half stays covered because W2/W3 commit it in the same call; the paths that return before them leave the record at the last committed cell, which IS the receipt's own cell - correctly not a supersession. Adding the term would decline receipts whose facts are still true, on the entity's FIRST world-visible moment: the pose write and RebucketLiveEntityPresentationOnly would be skipped while TryPublishPlace still publishes, so a packet returning before the render write would leave the sidecar visible at its materialized pose in a wrong bucket. That is the handoff's own "removed the invariant failure while leaving the bug" shape. There IS one supersession neither term covers, and it predates C5b: RuntimeRemotePlacementDriveController.StoreAcceptedDestinationPose writes body.Position/Orientation on the far-snap Refused/Contention arm with no placement commit and no cell move. Filed as #323 with the FIFO-blocking argument for why a receipt can still be pending when it lands, an explicit "not established as reachable", and an explicit "do not fix it with PositionAuthorityVersion". The guard's comment now carries the whole argument instead of one sentence. S1 - DANGLING POINTER CLOSED. InboundPhysicsStateController.cs:610 still said the two-callers-one-rule debt was "tracked for the eventual cutover unification ... See docs/ISSUES.md", which pointed at nothing after C5b closed #275 without a successor. Filed #322, cited from both the comment and #275's closure, including why widening TryApplyPosition's signature to take a route would be the wrong unification. AP-138 amended: C5b staled its round-3 measurement that "both accepted-Position callers commit the accepted wire cell to record.FullCellId before submitting". Route 2 submits from TryExecuteAcceptedLocalPosition ahead of W2, so on a first submit PlacementTouchesPrefix's CurrentCellId arm now names the SOURCE landblock, not the destination. Confined to which prefix the quiescence pre-flight matches, which that row already established is not the correctness mechanism. GATES. Release build 0 errors. Complete suite 11,134 passed / 4 skipped / 0 failed, from the 11,125 / 4 baseline at ed806997: net +9, all new tests, no test deleted or weakened, no new skip. Runtime.Tests 1195 -> 1202 (+6 mixed-motion-table rows, +1 park-rollback fact); App.Tests 4132 -> 4134 (+2 guid rows). None of #302/#308/#321 appeared. Not connected-gated - nothing here changes runtime behaviour. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-05 22:08:46 +02:00
Erik	ed8069976c	docs(register): restore AP-131 as a struck-through retired row (C5b follow-up) ... C5b deleted AP-131's row outright and recorded the retirement only in the AP section header, describing that as house style. It is not: the register carries 32 struck-through `~~ID~~` retired rows, including AP-1 and AP-145 retired one commit earlier in C5a, and the C5b contract explicitly mandated "rewrites the row's text to past tense with the evidence ... which the C5a/AP-1 and 4b-3/AP-137 rewrites established as the house style". A deleted row loses the evidence a header clause cannot carry, and leaves a reader who greps AP-131 with nothing rather than a retired row. Restored in the AP-1 shape, with one fact the header omitted and that is worth keeping: this row's own predicted retirement mechanism did not occur. AP-131 forecast "the legacy caller is deleted at the production cutover, retiring this row by construction" — the caller was corrected instead, and the steady-state merge remains a live production Position caller. That is the kind of prediction the register exists to be honest about. Active-row count is unchanged at 100; struck-through rows are retired, not active. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-05 21:20:36 +02:00
Erik	735f0a72af	fix(physics): classify before merge on every steady-state Position (C5b, #275, AP-131/AD-60) ... The steady-state accepted-Position merge did two things retail never does, on every single Position packet: it installed the wire placement frame and unparented unconditionally, and it derived the record's FullCellId from bare wire acceptance. Both are now correct, and they land together - a half-flipped intermediate (classified flags with the wire stamp, or vice versa) is exactly the mixed-residency state this campaign keeps paying for. WHY the flags need no route. SmartBox::HandleReceivedPosition @0x00453FD0 decides both pre-placement writes BEFORE MoveOrTeleport is consulted: Gate A @0x0045400C returns @0x0045409D ahead of unset_parent @0x00454129 and ahead of the HasAnims SetPlacementFrame gate @0x00454137. Neither gate reads the near/far/teleport classification. So the two flags are a pure function of (disposition, hasAnimations) and are computable inside the merge, pre-merge, with no signature change, no route construction and no playerDistance - the scoping's ~150-400-line route-plumbing estimate over-counted because it did not see this. That truth table IS RuntimeAuthoritativePositionRouteClassifier.ClassifyAcceptedPosition's own ApplyPlacementFrameBeforeRouting/UnparentBeforeRouting rows; the classifier stays the oracle and the equality is pinned by test, not by a shared path, so each computation remains separately sabotage-verifiable. WHY the cell is withheld. HandleReceivedPosition reads the wire objcell_id into a LOCAL @0x00453FE3 and hands it only to BlipPlayer / TeleportPlayer / MoveOrTeleport / ConstrainTo; it never assigns the object's cell. The object's cell moves inside the placement family (SetPositionInternal @0x00515BD0 to set_cell, enter_world) or per-frame transit, and nowhere else. The continuation executor has encoded that rule since the executor slice; this caller now matches it verbatim. WHAT DELIBERATELY SURVIVES. Two steady-state wire-cell writers stay, downstream of the merge and outside the classification window: the OnPosition prologue rebucket (W2, into CommitRebucket), which is also the local player's own cell-freshness path, and the post-routing wire-cell adopt for non-placing arms (W3, AP-135). Gating W2 "for symmetry" would freeze the player's canonical cell between teleports and #319's child-cell equality would inherit the freeze. AD-60's rewrite names both so the retirement cannot be misread as "wire acceptance never changes residency anywhere". REGISTER. AP-131 RETIRED - the unconditional literals no longer exist; the caller was corrected, not deleted, so the row's own "deleted at the production cutover" framing is overtaken. AD-60's legacy half RETIRED and the row REWRITTEN rather than deleted, naming W2/W3 (route 4b-3's D8 precedent: a silent whole-row deletion would hide surviving channels). AP-130 amended - the merge consumes the same static HasAnimations proxy, deliberately not escalated to a live animation-queue read. AP-146 and #320 amended - their "accepted inbound Position (RefreshSnapshot into RuntimeEntityRecord.cs:234)" local-player cell writer is now the generic tail's CommitRebucket, and a ForcePosition (which returns before that tail) is placement-receipt-authoritative. #275 closed. HEADLINE BEHAVIOURAL DELTA, stated once: a refused or contended local ForcePosition now leaves FullCellId at the last committed cell where the merge used to stamp the refused packet's wire cell. Retail cannot refuse (AD-62) and its body keeps its last placed cell, so the new shape is the retail-reachable one. THREE CONSUMER SITES THE CONTRACT'S BLAST-RADIUS SURVEY MISSED, all D2-caused, all found by the suite rather than by reading, all intended semantics rather than regressions (recorded in the contract's new section 14): (1) DatLiveEntityProjectionMaterializer's self-projection branch reads FullCellId inside OnPosition's prologue recovery, ahead of W2. It now correctly declines to project from an unplaced wire claim; production installs the bucket at W2 in the same call (verified: no return between the recovery call and W2 is conditioned on IsSpatiallyProjected or FullCellId). Two hydration tests asserted the bucket at the recovery boundary and now drive the production W2 step - the same shape as trap T2, one layer up. (2) ProjectileController.SyncPresentationFromResolvedBody writes ParentCellId = record.FullCellId. On a refused missile placement that is now the committed source cell. The MAJOR-1 invariant is unchanged and is now asserted as the identity it always meant rather than as a wire-cell constant. (3) The merge's Rebucketed ternary does NOT become always-Updated as the contract predicted, and is deliberately kept: the Forget(restoreCancelledPark: true) above it can roll a wakeable lost-cell park back, and RestoreParkWithdrawal restores canonical residency. That is a real cell edge produced inside this method by a placement owner. TEST-COUNT RECONCILIATION. Baseline measured at this HEAD by stashing the change: Runtime.Tests 1176, App.Tests 4135 (4132 passed / 3 skipped), solution 11,106 passed / 4 skipped - matching the recorded figure at 6921a027 exactly. Post-change: Runtime.Tests 1195, App.Tests 4135 unchanged, solution 11,125 passed / 4 skipped / 0 failed. Net +19, entirely new Runtime tests: 3 facts plus a 12-row matrix theory in InboundPhysicsStateControllerTests, 1 fact plus a 2-row theory in the new RuntimeSteadyStatePositionMergeTests, and 1 fact in RuntimeAcceptedPositionDriveControllerTests. No test was deleted; five existing tests were rewritten in place, never delete-only. No new skip; none of #302/#308/#321 appeared. SABOTAGE VERIFICATIONS (each new discriminating test, both directions; production line broken, suite run, line restored): installPlacementFrame (!force && !hasAnimations) to (!force) 5 fail: ApplyOnAnimatedEntity_NeverInstallsTheWirePlacementFrame plus the 4 animated non-force matrix rows. installPlacementFrame to false 6 fail: ApplyOnNonAnimatedEntity_InstallsTheWirePlacementFrame, PositionPlacementAbsentAndPresentZeroBothApplyRetailZero plus the 4 non-animated non-force matrix rows. clearParent (!force) to true 3 fail: ForcePositionOnParentedLocalPlayer_RetainsTheParentAttachment plus the 2 force+parented matrix rows. clearParent (!force) to false 4 fail: the 4 Apply+parented matrix rows. refreshPosition false to acceptedPosition 4 fail: AcceptedPosition_WithholdsTheWireCellAtTheMergeBoundary, ContendedForcePosition_WritesNoResidencyAnywhere, ReentrantNewerPositionDuringPickupDiscardSuppressesStalePickupDelta, MissileFarRefused_...ParentCellIdAgreesWithCommittedCell. Confirmed a second time by the baseline measurement above, where the withhold test was the sole red. CommitRebucket publishes Updated instead of Rebucketed 2 fail: both parent classes of CellChangingAcceptedPosition_ConservesOneRebucketAndOneChildPropagation. RuntimeEntityDirectory.SetFullCell drops PropagateFullCellToChildren 2 fail: the same two rows. T4 respected: the ForcePosition placement-frame half is inert (appliedPlacement keeps old.PlacementId under either flag value), so the force row's discriminating assertion is parent retention, never the frame. NOT DONE, deliberately: the executor is still not wired into the steady-state path (#275's alternative branch); W2/W3 are untouched; no probe added or stripped; AP-130's proxy not escalated; no while-here unification of the two merge callsites. No automated OnPosition-level test drives the full pickup / drop / reproject sequence (no fixture covers pickup at that layer); the contract's connected gate recipe item 1 is the positive evidence for it and has NOT been run - this commit is not connected-gated. Contract: docs/research/2026-08-05-c5b-contract.md (committed here, with its section 14 implementation outcome appended). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-05 21:17:44 +02:00
Erik	6921a02744	refactor(physics): delete legacy PhysicsEngine.Resolve/ResolvePlacement/HasCellSurface (C5a, AP-1/AD-1) ... Member-wise deletion of the three legacy resolver members named in docs/research/2026-08-05-c5a-contract.md: PhysicsEngine.Resolve, PhysicsEngine.HasCellSurface, and PhysicsEngine.ResolvePlacement. An exhaustive receiver census over src/ found zero production callers of any of the three — every production placement writer already reaches the canonical PhysicsEngine.SetPosition transaction exclusively through RuntimeSetPositionState (three call sites total). The deletion is purely member-wise: IsSpawnCellReady and AdjustPosition, which shared the same source region as the deleted members, are preserved byte-identical — every remaining production caller of either (including PhysicsCameraCollisionProbe, AdjustPosition's sole surviving production caller) is unaffected. Companion changes: - PlayerMovementController's 3-argument SetPosition test overload is renamed to SeedPlacementForTest (internal) and CommitPreparedPosition is deleted; 83 call sites across 19 test files were mechanically renamed to match. - Seven pinned test dispositions from the contract are executed: 3.1 (PhysicsEngineTests.cs: 11 legacy-resolver tests deleted, 6 ResolveWithTransition tests kept), 3.2/3.3/3.4 (re-point to canonical SetPosition, with TransitionScratchDifferentialTests.cs additionally gaining positive IsCommitted assertions after each bitwise comparison so the differential proves a placement actually committed, not just that two possibly-uncommitted results match), 3.5 (Runtime rename), and 3.6 (PlayerMovementPlacementTransactionTests.cs rewritten — its xmldoc now states plainly that the render-root publish moved to RuntimeSetPositionState.cs, but the sticky-release relocation claim was false and is retracted; this disposition's coverage loss is the sticky release path, not silently absorbed elsewhere). - Stale `PhysicsEngine.Resolve`/`Resolve` doc citations in CellTransit.cs, PlayerMovementController.cs, and HeadlessSessionWorldProjection.cs are corrected to name the surviving canonical entry points by symbol (SetPosition, AdjustSetPosition/AdjustPosition, ResolveWithTransition) rather than fragile line numbers. Retires AP-1 and AD-1 in docs/architecture/retail-divergence-register.md: both rows described production zero-delta placement routing remaining on the legacy resolver pending the Slice 4B2/4B route cutover; that resolver no longer exists, so the condition each row tracked is now structurally false rather than merely narrowed. AP-145 (routed through the prior commit) and this commit's AP-1/AD-1 together bring the section counts to 101 AP / 47 AD active rows. Builds on the AP-145 fix (previous commit) — this commit's staged tree was independently rebuilt and its four suites independently rerun on top of that commit before this commit was created, in addition to the combined rebuild/rerun below. Full-solution build: 0 errors (21 pre-existing warnings, all unrelated). Suite results (combined tree): Core 4270/4271 passed (1 skip; the single DatSoundCacheTests concurrent-decode-dedup failure is a known load-sensitive race, confirmed passing standalone and unrelated to this change), Runtime 1176/1176, Headless 86/86, App 4132/4135 (3 skips). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-05 14:11:31 +02:00
Erik	f8e55ba5e4	fix(physics): route local-player shadow presentation through SyncPose (#318, AP-145) ... RuntimePlacementPresentationSink.TryPublishPlace previously published the local player's collision-shadow pose with a direct LocalPlayerShadowState.Set call — a plain cache write that never touched PhysicsEngine.ShadowObjects. Because LocalPlayerShadowSynchronizer.SyncPose's own dedup check compares against that same cache, the direct write could pre-seed the cache with the destination pose and cause the next real SyncPose call to see "nothing changed" and skip its own ShadowObjects publish — leaving the real collision shadow at the pre-teleport position until an unrelated movement tick forced a real publish. Fix: TryPublishPlace now calls _localPlayerShadowSync.SyncPose(..., force: true), the same publisher ordinary per-tick movement uses, so Place always drives a real ShadowObjects write before the cache updates. TryPublishWithdrawal carried the exact mirror asymmetry (a bare LocalPlayerShadowState.Clear with no ShadowObjects.Suspend, leaving a live phantom shadow row at the park's source cell for the whole park window — the #184 shape) and is fixed in the same commit, same one-call shape: _localPlayerShadowSync.Suspend(entity). The sink no longer holds a direct LocalPlayerShadowState reference; both halves route exclusively through the one synchronizer, which owns the cache internally. The single LocalPlayerShadowSynchronizer instance is now constructed in LivePresentationComposition (before the sink) and threaded through LivePresentationResult to SessionPlayerComposition, which no longer builds its own — this guarantees the sink's Place/Withdraw edge and ordinary per-tick movement publish through the exact same publisher and cache rather than two independent instances that could drift out of sync with each other. TryPublishPlace's xmldoc now states the behavioural nuance directly: routing through SyncPose means Place inherits SyncPose's own admission guard (IsHidden, cellId == 0, not-current-visible-projection), which the old direct .Set() call never consulted. Under those conditions SyncPose now calls Suspend instead of publishing — correct and symmetric, but new behaviour worth flagging at the call site, not just in a test comment. RuntimePlacementShadowCompositionTests.cs (#318) proves four facts against the real ShadowObjects registry, not the cache: a bare Place publishes a real row at the destination cell with the source cell's row gone; a subsequent ordinary per-tick Sync is then a correct no-op; a Place for a registered non-local-player entity leaves its row at the source cell untouched and never touches the player's cache (route 7 P4 — the fix lives entirely inside the pre-existing player-only gate); and Withdraw suspends the real registry row, not just the cache, with the retained (suspendable) registration surviving for a later restore. All four were sabotage-verified in both directions. RuntimeForcePositionRenderCommitTests.cs (B2) drives a real end-to-end accepted ForcePosition through RuntimeEntityObjectLifetime.TryApplyPosition and RuntimeAcceptedPositionDriveController.TryExecuteAcceptedLocalPosition against a live HostFixture, asserting both the committed render position AND a cell change that deliberately crosses out of the spawn's outdoor grid cell, so the cell assertion is independently falsifiable rather than riding along with the position assertion. Retires AP-145 (this fix) in docs/architecture/retail-divergence-register.md. AP-1 and AD-1 are untouched by this commit — they retire separately in the deletion-sweep commit that follows. Evidence chain: docs/research/2026-08-05-c5a-contract.md (the governing C5a slice contract), docs/research/2026-08-05-c5a-architecture-review.md (round 1, FAIL — three MAJORs: vacuous route-7 P4 test, unfixed Withdraw-side mirror asymmetry, non-driving B2 test), docs/research/2026-08-05-c5a-architecture-review-round2.md (round 2, PASS with two MINORs — an unfalsifiable B2 cell assertion and the undocumented SyncPose guard nuance, both fixed here). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-05 14:09:11 +02:00
Erik	392c1e22c1	fix(physics): bind a parented child to the parent's live incarnation (#319) ... A player-parented child never received a canonical cell. Its FullCellId stayed 0 for its whole attached lifetime, so it could not follow the player across a boundary. Scope was wider than the local player: every REMOTE player's equipment too. ROOT CAUSE. EquippedChildRenderController hardcoded ParentInstanceSequence: 0 for a parented CreateObject. Correct for creatures and statics, which really are sequence 0; wrong for players, whose ObjectInstance is Character.TotalLogins (ACE Player_Networking.cs:37). The relation filed under (playerGuid, 0) while the record carried TotalLogins, so both route-7 write sites — D1's attach re-cell and D2's propagation lookup — keyed on an incarnation that never matched. TryCommitParent did not validate the sequence, so the attach succeeded and printed normally. Silent. A ROUTE 7 REGRESSION (cd3129e9) that un-masked a latent bug: the TickChild call route 7 deleted was keyed on the child guid alone and was structurally immune to a wrong parent key. THE FIX IS TO STOP TREATING PLAYERS DIFFERENTLY, not to special-case them. Retail's attach path is guid-only end to end — PhysicsDesc::get_parent_id @0x00558a18 -> CObjectMaint::GetObjectA @0x00558a2d -> set_parent @0x00558a3e, with SetChildren @0x00509370 hash-walking by guid — and neither set_parent overload (@0x00515A90, @0x00515B50) nor enter_cell @0x00510ED0 contains any player test or instance-sequence read. Our player/non-player split was purely an artifact of keying relations by (guid, incarnation) against a wire message that carries no parent incarnation. Late-binding to whoever currently holds the guid is retail's own semantics. Fixed at BOTH producers: OnSpawn and OnCreateParentAccepted, the second carrying the byte-identical defect and not named in the contract's scope line. THE INVARIANT IS EQUALITY, NOT FRESHNESS. The contract rejected both framings I offered: every one of the 45 FullCellId liveness predicates excludes a committed child on a NON-cell clause first, so the child inherits only the parent record's existing staleness, which is already present today with no symptom. The key fix alone restores child-equals-parent for every parent class. TWO SITES GATED, inert only because the cell was zero and would have woken wrongly: the hydration candidate loop (a nonzero-cell child would take the legacy RebucketLiveEntity -> CommitRebucket, a second canonical writer — route 7's exact defect class) and RestoreShadow (would install a broadphase row for the weapon, the #184 shape, contradicting route 7's P4). Retail anchor: update_object's parent != 0 early-out @0x00515D40 — children are never independently re-placed. THREE MAJORS WERE FIXED BY DELETION. The first pass added a deferral queue for an unaddressable parent, carrying a missing child-freshness gate (A2), a sentinel-0 collision with the generation filters (A3), and unbounded accumulation (A5). Both reviewers then proved the deferred branch unreachable for BOTH producers — RegisterEntityCore defers the entire CreateObject one layer above, reading the same ?? chain, and CreateParentUpdate is produced only inside AcceptCreateCore, after that gate passes. The machinery was deleted rather than repaired, and the diff SHRANK to 76 added / 13 removed from 91/24 while gaining the A1 fix. Retail confirmed the deletion does not diverge: acdream's real port of retail's per-guid replay (QueueBlobForObject) is a different, untouched layer, and the deleted queue was a third redundant one downstream of it. THE GUARD MUST NOT TEAR WHAT IT PROTECTS. The first pass threw InvalidOperationException AFTER the canonical half had committed, so the one time it fired it left the child parented with no committed relation and a staged one blocking Resolve — a torn transaction, the exact outcome the contract pinned against. Now a pure CanCommitIncarnation precondition checked BEFORE the commit at both sites, with a logged refusal instead of a throw. Route 3's N3 principle (do not make a transient fatal on a host that must survive 30 sessions x 2 hours) reinforces it, but the tearing argument stands alone. TEST QUALITY, the recurring lesson in its most refined form. The A1 test initially passed sabotage FOR THE WRONG REASON: a mismatched ChildPositionSequence meant TryCommitParent's own gate refused in either ordering, so the three assertions carrying A1's meaning passed both ways and only an incidental staging assertion failed. It failed on stranding, not tearing. Corrected, the sabotage now names line 925 — Assert.Null(snapshot.ParentGuid), with the parent's guid in it — proving the canonical mutation happened before the catch. "Fails under sabotage" is necessary, not sufficient; WHICH assertion fails is the real question. The dual parent-class matrix (player 0x5… incarnation > 1 vs creature 0x8… incarnation 0, identical outcomes, sabotage-verified in both directions) is the structural fix for how this survived a full dual review and two connected sessions: every prior test and both captured gate logs used sequence-0 parents. Register: AP-142 clause (f); AP-132 amended to distinguish the two producers; new row AP-146 for the local player's coarse canonical cell (retail writes it per tick at SetPositionInternal @0x00515330 — which, per the retail review, ALSO walks this->children writing each child's objcell_id @0x005153AE-@0x005153D8, so retail's per-tick child propagation lives in the same function). That divergence had no row at all, a standing rule-1 violation now corrected. Follow-up #320 filed for making the player's cell track ordinary movement — deliberately excluded here: it touches the landblock-preserve contract, the Rebucketed cadence, route-2/4b-3 classification inputs AP-136/AP-138 spent four review rounds pinning, and the portal-space frozen-source-cell race. Two dual review rounds; 6 architecture MAJORs and 2 retail MAJORs closed. Diagnostic refusals are latched per child guid and the latch clears on Clear()/RemoveChild, so a recycled guid's next incarnation still logs rather than being silently suppressed. Complete Release suite MEASURED at 11,112 passed / 4 skipped / 0 failed (baseline 11,090 at 52175aa1, +22). Neither known flake fired. STILL OWED: the connected gate, with the CORRECTED positive criterion — assert the equipped child's FullCellId EQUALS the parent's after a crossing (a zero is a failure, not a silence), run with BOTH a player and a creature parent, plus the new step carrying an armed creature across a landblock unload/reload. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-05 11:56:31 +02:00
Erik	e0f96a55bf	fix(physics): C4 route 3 — portal placement authority (local player) ... Removes a duplicate placement authority for local-player portal arrival. Portalling worked before this change and works after it — this is not a bug fix, EXCEPT that it found and fixed one dead-code production bug. THE PRODUCTION BUG: TryExecuteCanonicalPortalPlacement re-read the accepted destination at Place time, but TryBeginPortalReveal already consumes that slot at Aim time — so the arm was 100% dead code and every real portal Place refused with host-token-unavailable. Found only because we refused to accept 7 skipped tests instead of chasing the count to zero. RETAIL IS THE GENERIC PATH FOR THE THIRD ROUTE RUNNING: SmartBox::TeleportPlayer @0x00453910 = SetPositionSimple(dest, 1) with flags 0x1012, followed by PlayerPositionUpdated. BOTH INVERSIONS, WITH THEIR ANCHORS: unlike route 2, the leash IS armed here (ConstrainTo @0x0045418A) and velocity is zeroed (set_velocity @0x004541B4); unlike route 4b-3, the local teleport_hook runs AFTER placement (@0x004538AE). THE THREE-ROUND DEFECT CHAIN, HONESTLY: - Round 1 released the player at the pre-teleport position while the anim stream marched on — the contract wrongly assumed Place re-fires (process rule 1's third occurrence this campaign). - Round 2's fix inferred commit from a global PendingCount, which three non-committing paths also clear — making the SAME bug complete cleanly and silently. Strictly worse than round 1: round 1 at least tripped portal-complete-before-materialized. - Round 3 latches the commit where it actually happens (ReconcileAndAcknowledgePortal), keyed on reveal generation and teleport sequence, via TryConsumePortalCommit. Two of the three required regression tests landed and are sabotage-verified on both hosts (ParkedPlace_ForgottenByOrdinaryMergeDoesNotLatchAsCommitted / HeadlessPortalPrepareDestinationForgottenByOrdinaryMergeDoesNotLatchAsCommitted). The third (force-arm-takes-the-slot) was judged unnecessary on review: with the inference gone, PendingCount is only a "don't ask yet" guard at both gates, so a force operation occupying or vacating the slot no longer changes an input the commit decision reads — the case collapses into what the landed test already discriminates. THE B2/P3 RESOLUTION: both round-2 reviews were right about different branches of the same synchronous call. RuntimePlacementProjectionSubscription .OnPlacement acknowledges the FIFO head only when TryApply returns true; a Place whose portal authority went stale (transit ended/superseded while parked) used to return false, wedging every later entity's placement receipt behind it forever. Both sinks (RuntimePlacementPresentationSink, HeadlessRuntimePlacementProjectionSink) now acknowledge-and-ignore a stale-authority Place instead of refusing it. The regression test (RuntimePlacementPresentationSinkTests .PortalPlace_StaleTransitHostOrSequenceIsAcknowledgedAndIgnored) had been asserting the old, wrong `false` behaviour; it now asserts and sabotage-verifies the fix. Also lands: AP-144 (register discipline — the portal movement-event send reuses the stricter UsePositionFromServer gate where retail's SendMovementEvent is the looser autonomy_level != 0 test, diverging only at level 1, currently unreachable), AP-145 + issue #318 (the local-player collision-shadow presentation write bypasses its own publisher's ShadowObjects write via a direct cache .Set(), self-healing only once dedup diverges — filed, not fixed, pending a composition test), AD-42 deleted (its last citation retired by the canonical portal arm), AD-2 updated (the wait-cue's trigger predicate now covers a second cause), and two documentation corrections: the enter_world misattribution (both call sites are in SmartBox::HandleCreateObject, only one in the player branch — portal arrival is TeleportPlayer, not enter_world) and the stale "local player never reaches this path" comment on the generic-remote-render-pose write. Suite: 11,090 passed / 4 skipped / 0 failed. No new skips, nothing weakened. STILL OWED: the connected two-client gate, with ACDREAM_PROBE_LOCAL_TELEPORT=1, scored only if [local-tp] lines actually appear in the capture — and explicitly NOT scored as covering issue #318 (no composition test yet asserts PhysicsEngine.ShadowObjects directly). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-05 03:57:37 +02:00