acdream/docs/research/2026-08-12-fa5-review-mechanism.md

Campaign FA slice FA5 — mechanism-faithfulness review

Reviewer lens: mechanism-faithfulness (retail-fidelity), read-only. Date: 2026-08-12. Target commits: 7ed79eaf (code+tests), bc29a1db (register/gate-script/ledger), 7e394cbf (NUL-byte repair). Contract: docs/plans/2026-08-11-fellowship-allegiance-campaign.md §FA5 (CORRECTED row — 0x001F subscription, NOT 0x027B) + lane-C allegiance-wire doc + fa-panel-structure §3.2/§10. Worktree HEAD at review: b6c4a4fa (clean).

---

VERDICT: APPROVE-WITH-FIXES (one SHOULD-FIX, LOW severity)

FA5 is mechanism-faithful. Every high-stakes claim was re-derived from the PDB-paired 2013 decomp (not trusted from the implementer's summary): CF-1's unconditional 0x001F post-world arm, the monarch/patron/self field sources, the per-relationship SF-7 gate, the swear/break/kick targets, and the ACE-zeroed-field honesty all match retail. The mandatory live-mount probe PASSED against the real installed DATs (the anti-fixture-green safeguard the implementer could not run) — including the doubled-0x10000492 scoped dual-resolution that is exactly where a live-only defect could have hidden.

The single SHOULD-FIX is a LOW-severity invented-visual: FA5 greys an offline vassal's name (OfflineNameColor), which retail does not do — retail's offline indication is exclusively the authored 0x100004AA marker toggle, with the name left at normal color. The AD-82 addendum mentions OfflineNameColor but frames it as "already covered by the retail-authored 0x100004AA marker," which understates it: the name-grey is an additional cue retail never paints. This does not block the connected gate (data + the authored marker are correct); it needs either removal or an honest register entry.

---

Live-mount probe — actual output (MANDATORY, reported explicitly)

Run: ACDREAM_PROBE_LIVE_MOUNT=1, ACDREAM_DAT_DIR=%USERPROFILE%\Documents\Asheron's Call, dotnet test tests/AcDream.App.Tests -c Release --no-build --filter "FullyQualifiedName~SocialPanelLiveMountProbe". The App test project was rebuilt first (with dependencies) since this fresh worktree's artifacts predated FA5.

Result: Passed! - Failed: 0, Passed: 1, Skipped: 0 (exit 0). SocialPanelLiveMountProbeTests.ProbeLiveMountShapes [84 ms].

The probe is NOT a no-op green — against live DATs it asserts (all held):

• Assert.Equal(2, passupCount) — 0x10000492 occurs exactly twice under the allegiance page.
• The scoped dual-resolution: monarchScopedPassup found under 0x10000490 (under monarch field 0x10000255), patronScopedPassup found under patron field 0x1000025A, both non-null AND Assert.NotSame — proving the two FindDescendant sites resolve to DIFFERENT real instances. A flat/unscoped lookup would silently pick one for both roles; this catches it.
• Vassal ListBox 0x10000260 template resolves via the production RowTemplateResolver; row fields 0x10000268/0x10000269 (UiText), 0x100004AA (offline marker) all resolve.
• Checkbox 0x10000262 (UiButton) + label ID_PlayerOption_IgnoreAllegianceRequests resolves non-empty.
• All five allegiance strings resolve non-empty: ID_Allegiance_MonarchLabel, PatronSlashMonarchLabel, SwearConfirmation, BreakConfirmation, KickConfirmation.
• A full production SocialAllegiancePageController.Bind() against the live layout emits zero "not found" console warnings.

The raw dump confirms 0x10000490 is authored under BOTH the monarch field (0x10000255, at (210,0 90x36)) and the patron field (0x1000025A, at (220,0 80x36)); FA5's monarch-experience lookup scopes to the monarch instance, and its patron-experience lookup recurses from the patron field (finding the patron instance) — matching retail's own GetChildRecursiveTemplate(sub-block, …) vs GetChildRecursive(m_pPatronField, …) split (see item 2).

FA5 unit suite (targeted, this build): SocialPanelControllerTests + GameplayConfirmationControllerTests = 36 passed / 0 failed.

---

Per-item verification (re-derived from primary source)

1. CF-1 — the 0x001F subscription (highest stakes) — VERIFIED

Unconditional post-world arm (the core claim). pseudo-c:157175, gmAllegianceUI::RecvNotice_PlayerDescReceived @0x00490D40:

if (m_bAwaitingUpdate == 0) { m_bAwaitingUpdate = 1; IncrementBusyCount(); }
CM_Allegiance::Event_UpdateRequest(1);   // 00490d59 — OUTSIDE the if

The Event_UpdateRequest(1) at 00490d59 sits OUTSIDE the if guard (which only wraps the busy-count increment), so retail sends 0x001F(1) unconditionally, exactly as the implementer claims. SocialAllegiancePageController.RedeclareAfterWorldEntry() mirrors this: it calls SetUpdateSubscription(true) with no latch comparison, and advances the latch only on Accepted (so a dropped send retries).

Three arming points, all confirmed against the decomp (every Event_UpdateRequest site enumerated): PostInit @0x004911C6 → 1 (Bind's SetPageVisible(true) attempt, pre-world no-op in production), OnVisibilityChanged visible @0x004912DD → 1 / hidden @0x00491311 → 0 (edge-triggered SetPageVisible), PlayerDescReceived @0x00490D59 → 1 (RedeclareAfterWorldEntry, unconditional). A fourth retail arm exists — OnQualityChanged @0x00490DC9 → 1 (Patron/Monarch instance-id change, fa-panel-structure §6.3) — NOT modeled by FA5; covered instead by acdream's 0x0020-seed + Revision polling. Given the subscription model (data streams while subscribed), this is a benign data-refresh-mechanism substitution, not a functional gap.

Genuinely avoids MF-3-REOPEN. Reconnect seams traced end-to-end: pre-world LiveSessionResetBindings.SessionDialogs → ResetSessionTransientUi → SocialPanelController.ResetSessionDeclaration → _allegiance.ResetPageVisibleLatch() (clears latch, no send); post-world EnteredWorld.RestoreLayout → RedeclareSocialPanelAfterWorldEntry → SocialPanelController.RedeclareAfterWorldEntry → _allegiance.RedeclareAfterWorldEntry() (unconditional send). So a reconnect while the panel is CLOSED still re-subscribes.

The test genuinely exercises the world gate. Reconnect_ReDeclaresSubscription_AfterWorldEntry_EvenWhilePanelClosed binds with the window never shown (_visible=false), clears the latch, then asserts RedeclareAfterWorldEntry records subscription:True. This only passes because the path is unconditional — a conjunction-gated shape (UpdateAllegiancePageVisibility) would compute false && … = false, and with the latch already false would send nothing, failing the assertion. Confirmed it would fail against an edge-triggered shape.

0x027B is NOT wired for data. FA5's sole subscription surface is SetUpdateSubscription (0x001F); no info-request send exists in the controller. Class doc and gate-script both state 0x027B/0x027C are text-only chat (FA2 MF-2). Confirmed.

2. Monarch/patron/self blocks (SF-7 rewrite) — VERIFIED (all field sources)

Re-decompiled UpdatePlayerData @0x00491330, UpdateMonarchData @0x00491B40, UpdatePatronData @0x004917C0 fresh:

• 0x10000251 = the ALLEGIANCE name, not the viewer's. 00491397: m_pAllegianceName ← _allegiance.m_AllegianceName via AddVariable_String. FA5 RefreshSelfBlock uses snapshot.AllegianceName. ✓
• Self followers 0x10000252 = _total_vassals. 00491506: AddVariable_Int(_total_vassals) → m_pPlayerFollowers. FA5 snapshot.TotalVassals. ✓
• **Self rank 0x10000253 = InqInt(qualities, 0x1e) (AllegianceRank)
  • GetTitle.** 00491578: CBaseQualities::InqInt(&var_1f8[0xe], 0x1e, …) then AllegianceData::GetTitle. FA5 substitutes snapshot.Rank (documented data-source substitution). ✓
• Monarch gate = hide when monarch==viewer || monarch==0. 00491c0f. FA5 hasMonarch = monarch is {} m && m.CharacterId != selfGuid (null when no monarch). Matches under all cases. ✓
• Hidden branch blanks name AND followers. 00491f8c (m_pMonarchName ← "") and 00491fcd (m_pMonarchFollowers ← ""). FA5 blanks both. ✓
• Shown followers = _total_members - 1. 00491eac: ecx_43 = ebx_3->_total_members - 1. FA5 TotalMembers - 1 (guarded). ✓ (test asserts "2" for TotalMembers=3).
• patron==monarch → PatronSlashMonarchLabel + reveal 0x10000490 sub-block + 0x10000492 = viewer's CpTithed. 00491c60 (else of GetPatron != monarch): sets label, GetChildRecursive(0x10000490) ->SetVisible(1) 00491cbc, GetChildRecursiveTemplate(sub-block, 0x10000492) with GetData(viewer).cp_tithed. FA5 maps patronIsMonarch → PatronSlashMonarchLabel, subBlock.Visible=true, monarchExperiencePassedUp ← Member(self).CpTithed. ✓ patron!=monarch → MonarchLabel + hide sub-block (00491dc5). ✓
• Enabled ← IsLoggedIn (SetState(1) vs SetState(0xd) 00491f0c). FA5 _monarchField.Enabled = monarchData.IsLoggedIn. ✓
• Patron gate = hide when patron==0 || patron==monarch. 004918b1. FA5 hasPatron = patron is {} p && (monarch is not {} m || p.CharacterId != m.CharacterId); negation matches retail in all four cases (verified case-by-case). ✓ Shown: name = GetFullName (004918e0); Enabled ← IsLoggedIn (0049197d); experience GetChildRecursive(m_pPatronField, 0x10000492) = viewer's own tithed (004919b9 GetData(viewer)). FA5 matches (patronExperiencePassedUp ← Member(self).CpTithed). ✓

The doubled-0x10000492 scoping matches retail exactly: monarch's under the sub-block, patron's recursively under the patron field. FA5's two FindDescendant sites (Bind, lines 315-319) reproduce this precisely.

3. Vassal list — VERIFIED

RuntimeAllegianceState.AllegianceView.GetVassals returns AllegianceProfileLookups.FindVassals order — the FA1-assembled REVERSE-wire order (each record prepended, doc comment cites lane C §4.4). FA5 RefreshRoster materializes new List<>(Vassals(self)) and iterates with no re-sort; RebuildRoster uses FlushPreservingScroll() (NOT Flush()), so the FA3 scroll-reset carry-forward is NOT reintroduced. The allocating GetVassals call runs only inside the snapshot.Revision != _lastRosterRevision gate — not per-frame (honoring FA2's blast SF-7 caution). ✓

4. Swear/break/kick targets + type-1 confirmation — VERIFIED

• Swear = WORLD selection. UpdateSwearButton @0x004908E0 gates on GetPatron(self)==0 && selectedID!=0 && selectedID!=self && IsPlayer(selectedID) && GetData(selectedID)==0, where ACCWeenieObject::selectedID is the world selection. FA5 reads Selection.SelectedObjectId at click, resolves via ResolveWorldObjectName (= Objects.Get(guid)?.GetAppropriateName(), the same ClientObjectTable resolver ToolbarRuntimeBindings.ResolveName uses). ✓ The one omission — IsPlayer() — is registered AD-84 (same class as AD-83). ✓
• No SetSelectedObject for Allegiance's list (fa-panel-structure §6.2): Allegiance's ListenToElementMessage idMessage-4 reads the row's 0x10000001 into m_iidSelectedVassal only — no ACCWeenieObject::SetSelectedObject (Fellowship's DOES call it). FA5's panel-local _selectedVassalGuid with no world-sync is faithful, and the FA4 world→panel sync is NOT reintroduced for Allegiance. ✓
• Break = current patron (UpdateBreakButton @0x004909D0: GetPatron!=0; MakeBreakConfirmationDialog @0x00492BF0). FA5 OnBreakClick → Patron(self) → Break(patron.CharacterId). ✓
• Kick = panel-local selected vassal (MakeKickConfirmationDialog @0x00492E10, m_iidSelectedVassal). FA5 OnKickClick → _selectedVassalGuid → Kick. ✓
• Type-1 confirmation reaches the generic controller. RetailUiRuntime.HandleConfirmationRequest forwards every request straight to GameplayConfirmationController (no intercept — FA4's type-4 removal never touched type-1). New test AllegianceSwearRequest_Type1_OpensDialog_MessageVerbatim_AndSendsAcceptOnClose verifies a ConfirmationType 1 opens a verbatim dialog and sends accept on close. ✓

5. ACE-zeroed fields (AD-86) — VERIFIED (citations accurate)

references/ACE is not checked out in this worktree, so lane C §5.1 is the authority. AD-86's cited lines match it field-for-field: AllegianceHierarchy.cs officers :74-75, officerTitles :78-83, motd/motdSetBy :86-89, nameLastSetTime/isLocked/approvedVassal :62-64/:153-155, broadcast counters :53-56; AllegianceData.cs timeOnline/allegianceAge :59-60,86-89,111-112. Retail's own gmAllegianceUI has no widget for any of them (fa-panel-structure §3.3), so dropping them past the parse layer matches retail's presentation. The register row, blast column, and lane-C pointer are all accurate.

6. §6 DISCIPLINE compliance — VERIFIED

• Resolver on every Build. Main panel Build passes resolver.Resolve (RetailUiRuntime.cs:2715); the vassal row RowTemplateResolver builds each template with strings.Resolve (:2765). ✓
• Doubled 0x10000492 scoped under each parent (both sites found): monarch under monarchIsPatronSubBlock (0x10000490), patron under patronField — probe-confirmed NotSame. ✓
• No lazy 0x0. All FindDescendant failures null-check + log; no magenta-placeholder id path. ✓
• BlankSentinel is compare-only and never displayed. Used solely in SetProvider's lastValue == sentinelValue / lastValue = sentinelValue; the rendered text comes from BlankLineProvider ([new UiText.Line(" ", …)], a literal single space). The NUL-repair commit 7e394cbf restored the two spaces; byte-swept all 11 FA5-touched files (src/tests/docs): NUL=0, control-char=0. ✓

7. Retail anchors + gate-script §FA5 — VERIFIED

Five+ anchors spot-checked and confirmed: Event_UpdateRequest site inventory (157175/157212/157414/157455/157495); UpdateSwearButton enable rule; UpdateBreakButton; UpdateVassalsData @0x00492340 (offline marker SetVisible(1) when !IsLoggedIn @004925b1; row identity via SetAttribute_InstanceID(0x10000001)); the Update() ordering (self→monarch→patron→vassals→swear→break→kick, pseudo-c:158677+) matches FA5's Tick.

The gate-script §FA5 correctly avoids the false-route the reviewer flagged: it explicitly states the panel populates via 0x001F→0x0020 on tab-show, and says "Do not use @allegiance info as a trigger for anything in this section." The FA3 section (already corrected in FA3's fix round) is consistent — it tells the user FA3 does NOT send 0x001F and @allegiance info won't reveal the panel. Step 4 correctly describes the unconditional post-world resend as the MF-3-REOPEN analogue; steps 5-8 pre-empt the AD-85 "just a number" and SF-7 per-relationship false reports. No wrong step.

---

SHOULD-FIX (numbered)

SF-1 (LOW) — offline vassal name-grey is an invented visual not in retail; register or remove it. UpdateVassalsData @0x004924c3 sets the vassal name (0x10000268) via GetFullName with no color argument; retail's only offline indication is the dedicated 0x100004AA marker toggle (@004925b1: SetVisible(1) offline / (0) online). SocialAllegiancePageController.UpdateRow (SocialAllegiancePageController.cs:708) additionally renders the offline name in OfflineNameColor (0.6,0.6,0.6,1) — a grey retail never paints. The AD-82 FA5 addendum mentions OfflineNameColor but frames it as "already covered by the retail-authored 0x100004AA marker," which understates it: the marker is faithful; the name-grey is a separate additional cue on top of it. Fix: either (a) render vassal names in TextColor unconditionally (drop OfflineNameColor), letting the authored 0x100004AA marker carry the offline state exactly as retail does — the more faithful option — OR (b) correct the AD-82 addendum to honestly register the offline name-grey as an adaptive cue rather than claiming no invented tints are used. Does not block the connected gate (data + marker are correct).

---

Minor observations (NOT fixes — no action required)

• OnQualityChanged/quality-handler re-subscription arms (Patron 0x19/Monarch 0x1A instance-id change → Event_UpdateRequest(1), 00490dc9, fa-panel-structure §6.3) are not modeled. Benign: acdream's subscription-plus-0x0020-revision-polling refreshes the data through a different mechanism. Not a functional gap.
• SetTalkFocusEnabled(4/5/6, …) (patron/monarch/vassal chat-focus toggles, tail of each Update* function) are not modeled — a chat-integration nicety outside the panel-display scope.
• Monarch label LinesProvider is reassigned unconditionally each Tick in the shown branch (RefreshMonarchBlock:555) — a per-frame closure/list allocation, unlike the guarded SetLine used for name/followers. Blast-lens perf nit (rarely changes; could be guarded); not a mechanism concern.
• NIT: AD-86's prose says "seven fields" but the parenthetical lists nine (7 AllegianceProfile + 2 AllegianceData). Cosmetic; the field list and citations are complete/correct.

---

What verified clean (explicit)

• Live-mount probe: PASSED against real DATs (1/1), including the scoped doubled-0x10000492 NotSame assertion and full production Bind() with zero "not found".
• CF-1's unconditional post-world 0x001F arm is byte-faithful to RecvNotice_PlayerDescReceived and genuinely closes MF-3-REOPEN; the decisive reconnect test exercises the world-closed gate.
• All monarch/patron/self field sources match a fresh decompile of UpdatePlayerData/UpdateMonarchData/UpdatePatronData.
• Vassal roster: FA1 reverse order preserved, no re-sort, FlushPreservingScroll (no scroll-reset), revision-gated (not per-frame).
• Swear=world-selection / Break=patron / Kick=panel-local; no SetSelectedObject for Allegiance; type-1 confirmation flows to the generic controller.
• AD-84/AD-85/AD-86 + AD-82 addendum are accurate (AD-86's ACE citations match lane C §5.1 line-for-line).
• §6: resolver on every Build; doubled ids scoped; no lazy 0x0; BlankSentinel compare-only; zero NUL/control-char corruption across all 11 FA5 files after 7e394cbf.
• Gate-script §FA5 states the true 0x001F-not-@allegiance-info expectation — no false-route.