docs: Campaign P Slice P4 - record the Opus review fix-first outcome

P4's original AP-71 landing shipped CanMoveInto deliberately unmodeled
(fail-closed default, AP-129). The review found this locks the entire
housing estate (103,766 of 729,888 installed EnvCells) for every player
including its own owner. Records the fix (7a0f836a) and the updated gate
totals.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Erik 2026-07-30 11:37:05 +02:00
parent 7a0f836af5
commit 19d840cb63

View file

@ -149,17 +149,39 @@ binds every subagent here.
### P4 — World specials — retires AP-71, AP-10
**Status (2026-07-30): COMPLETE.** AP-71 landed at `d6c3f865` (20 new
conformance tests); AP-10 landed at `cc8d57a2` (12 new conformance tests).
`AcDream.Core.Tests` alone passes 4,038/0/2 after both slices (up from the
4,026/0/2 pre-slice baseline). Complete solution suite at the slice gate:
**Status (2026-07-30): COMPLETE**, including a same-day Opus review
fix. AP-71 landed at `d6c3f865` (20 new conformance tests); AP-10 landed at
`cc8d57a2` (12 new conformance tests). Complete solution suite at that gate:
9,946 total across 9 test projects, 9,941 passed, 5 skipped, 0 failed on a
clean run. One run in the same session saw a single unrelated flake
(`AcDream.Content.Tests.Vfx.RetailDatLoaderTests
.AnimationCache_CoalescesSameDidAndAllowsUnrelatedReadsInParallel`, a
parallel-cache-coalescing timing test untouched by either commit) that
passed 3/3 in isolation and on the immediate re-run — full-suite parallel
contention, not a regression.
contention, not a regression (independently fixed afterward at `dc0468cc`).
**P4 review verdict: FIX-FIRST (2026-07-30).** `RestrictionObjPrevalenceInspectionTests`
(`3b5e0992`) measured the installed cell DAT: 103,766 of 729,888 EnvCells
across 1,293 landblocks — the entire housing estate, `restrictionObj` GUIDs
`0x70xxxxxx` — carry a baked `RestrictionObj`. AP-71's fail-closed default
(landed with `CanMoveInto` deliberately unmodeled, per the original AP-129
row) would have locked every apartment/cottage/villa interior for every
player, including its own owner — a live regression, not the "inert in dev
content" the row assumed. Fixed at `7a0f836a`: `ACCWeenieObject::CanMoveInto`
(0x0058da40) and `RestrictionDB::IsAllowedIn` (0x005ae8f0) are now ported
verbatim, fed end-to-end from CreateObject's HouseOwner/HouseRestrictions/
Monarch PWD-tail fields (previously parsed-and-discarded) plus a new live
`House_UpdateRestrictions (0x0248)` parser, and resolved through a new
`PhysicsEngine.Objects` property wired to the canonical `ClientObjectTable`
in `RuntimeEntityObjectLifetime` (production fix, not just gate logic — an
unwired table still fails closed). AP-129 is narrowed (not retired) to the
genuine residual: no sequence-based staleness rejection for
`House_UpdateRestrictions` (low-probability, self-correcting), and the
outdoor `CLandCell` restriction path (a separate DAT structure) remains
unported, unaffected by this fix. Gate: `AcDream.Core.Tests` 4,049 passed / 2
skipped / 0 failed; `AcDream.Core.Net.Tests` 761 passed / 0 skipped / 0
failed; complete solution suite 9,961 total, 9,956 passed, 5 skipped, 0
failed.
1. **AP-71:** port the `CObjCell::check_entry_restrictions` gate at the
head of `find_env_collisions` (pc:309576) — barred house cells block
@ -171,9 +193,10 @@ contention, not a regression.
plain per-cell DAT field, not a live wire override) in both the dev
and production caching paths, at zero bake-format cost. The mover's
`CanBypassMoveRestrictions` (BF_ADMIN & BF_IMMUNE_CELL_RESTRICTIONS)
is decoded via the TS-23 PWD-bitfield pipeline. Remaining gap (no
`CanMoveInto` owner/guest-list model) filed as AP-129, replacing the
retired AP-71 row.
is decoded via the TS-23 PWD-bitfield pipeline. The original landing
deliberately left `CanMoveInto` unmodeled (fail-closed default, filed
as AP-129) — the P4 review found this fails closed for the ENTIRE
housing estate and required the fix-first pass described above.
2. **AP-10:** restore retail's 0.1 m water sink-in; while there, verify
the water-contact step behavior (`WATER_CONTACT_TS` consumers)
against retail and file anything found. Landed: the dry-corner