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

Campaign FA slice FA3 — MECHANISM-FAITHFULNESS review

Target: 0a9ca2f1 (feature), 74c3d85d (fixture + tests), b6a25110 (gate script + ledger), d7e1cffd (research addendum), reviewed against docs/plans/2026-08-11-fellowship-allegiance-campaign.md slice FA3 + D1 + §6 and docs/research/2026-08-11-fa-panel-structure.md (incl. §10 + the FA3 correction addendum).

Verdict: APPROVE-WITH-FIXES — 2 MUST-FIX (both in the user's connected-gate script, which is the artifact the user actually reads while gating), 9 SHOULD-FIX. The load-bearing tab-table correction is CONFIRMED CORRECT by re-derivation from the authored bytes AND independently from the installed DATs. No code defect found in the mount path.

Method note: every claim below was re-derived, not taken from the commit messages. The fixture was parsed directly; the env-gated live-mount probe was run against the installed DATs; the retail anchors were re-read in acclient_2013_pseudo_c.txt; and one BN string operand was byte-verified in the PDB-paired binary (check_exe_pdb.py → === MATCH ===, GUID 9e847e2f-777c-4bd9-886c-22256bb87f32).

---

1. The tab-table correction — VERIFIED CORRECT (item 1)

This was the load-bearing fact. It holds, three independent ways.

(a) The authored 0x2E array, read straight out of the committed fixture (tests/AcDream.App.Tests/UI/Layout/fixtures/social_panel_2100006E_1000018F.json, root 0x1000018F, property 46 = 0x2E, four Kind 8 struct entries with sub-properties 48=0x30 button, 49=0x31 page, 50=0x32 IsDefault):

entry	P0x30 (button)	P0x31 (page)	P0x32
0	268436108 = 0x1000028C	268436113 = 0x10000291	true
1	268436110 = 0x1000028E	268436114 = 0x10000292	absent
2	268436754 = 0x10000512	268436755 = 0x10000513	absent
3	268436795 = 0x1000053B	268436810 = 0x1000054A	absent

This is exactly the pairing recorded in SocialPanelController.cs:34-37, and Allegiance (0x1000028C→0x10000291) is the sole IsDefault entry.

(b) Each button's own resolved caption — from the live-mount probe run against the installed DATs during this review:

[socialprobe] tab button 0x1000028C (UiText) caption='Allegiance'
[socialprobe] tab button 0x1000028E (UiText) caption='Fellowship'
[socialprobe] tab button 0x10000512 (UiText) caption='Friends'
[socialprobe] tab button 0x1000053B (UiText) caption='Squelch'

(c) Each page's own P0x57 + its RegisterElementClass type, both from the fixture and re-confirmed by the probe:

page	authored Type	retail class (verified in pseudo-C)	P0x57
0x10000291	0x1000002C	RegisterElementClass(0x1000002c, gmAllegianceUI::Create) @004911fa	0x1000000E = ToggleAllegiancePanel (F3)
0x10000292	0x1000002D	RegisterElementClass(0x1000002d, gmFellowshipUI::Create) @0048e6aa	0x1000000F = ToggleFellowshipPanel (F4)
0x10000513	0x10000045	RegisterElementClass(0x10000045, gmFriendsUI::Create) @0048e21a	0x10000118
0x1000054A	0x10000047	RegisterElementClass(0x10000047, gmSquelchUI::Create) @0048d04a	0x10000124

The class doc's further claim that 0x10000118/0x10000124 carry no retail-default keybind is also correct: neither literal appears in keymap-default.txt or retail-default.keymap.txt.

A fourth corroboration the addendum did not state, and should have. With the corrected pairing, the authored x-order becomes Allegiance (x=0), Fellowship (x=72), Friends (x=144), Squelch (x=206) — i.e. the authored default tab is also the left-most tab, which is what one would expect and which the old (refuted) guess did not produce. Button widths track caption lengths under the corrected mapping too (Friends, the shortest caption, is the narrowest button at 62px). This same x-order is the basis of MUST-FIX 1 below.

Also verified: root P0x10000029 = 12 (the RetailPanelCatalog.SocialPanel byte-verification claim), root P0x57 = 0x1000000D, close button 0x10000290 P0x12 = 0x1000000D, and 0x1000000D really is an InputMap context id (ID_InputMap_ToggleChatEntry, src/AcDream.Core/Input/RetailActionMap.cs:161; it appears as Context 0x1000000D in keymap-default.txt) — so the class doc's "authored but UNCONSUMED" reading is accurate, not a hand-wave.

---

MUST-FIX

MF-1 — the gate script carries the REFUTED x-order into the user's contract

docs/research/2026-08-12-campaign-fa-test-script.md:59-64 (step 9):

"left-to-right authored order is Friends, Allegiance, Fellowship, Squelch"

and :20-25 (step 1):

"the authored default tab — NOT Friends, despite Friends being drawn left-most on the tab strip in some sort orders"

Both are wrong. The authored geometry (fixture, corroborated by the probe's root-child dump) is:

0x1000028C "Allegiance"  x=0    72x25
0x1000028E "Fellowship"  x=72   72x25
0x10000512 "Friends"     x=144  62x25
0x1000053B "Squelch"     x=206  70x25
0x10000290 (close X)     x=276  24x25

Friends is drawn third, not left-most. This is the same x-order guess d7e1cffd corrects in the research doc — it just never got corrected in the script. Step 10's caption list (:65-68) repeats the wrong ordering.

Why this is MUST-FIX and not a nit: the script is the user's contract for the connected gate, and step 1 explicitly primes the user to expect Friends at the left edge next to a tab that opens by default. The user will see Allegiance at x=0 and has been told that is the wrong-looking case. Fix step 9, step 1's parenthetical, and step 10 to the real order — and take the opportunity to say "the default tab is also the left-most tab", which is the most reassuring form of the correction.

MF-2 — the gate script's step 14 sends the user to a trigger that CANNOT fire, and tells them to report it if it doesn't

docs/research/2026-08-12-campaign-fa-test-script.md:100-107 (step 14):

"If some other client action causes an allegiance push to land server-side during this session (e.g. a @allegiance info chat command, which already works independently of this panel), the monarch/patron blocks should then become VISIBLE — report if they do not."

and the matching "What to report" bullet at :153-155:

"The Allegiance page's monarch/patron blocks staying hidden after a real allegiance push has visibly landed (e.g. after @allegiance info shows non-empty data in chat)."

RuntimeAllegianceState._hasProfile is set in exactly one place — ApplyUpdate (src/AcDream.Runtime/Gameplay/RuntimeAllegianceState.cs:126-142), whose own doc comment reads "0x0020 AllegianceUpdate — … the ONLY inbound writer of this owner's profile (see the class doc's MUST-FIX 2 correction)". FA2's own fix round deliberately stopped 0x027C (the @allegiance info response family) from seeding this owner (4272ad0e, "0x027C stops seeding"; GameEventWiring.cs:231 documents it), and the plan's FA5 row states the 0x001F subscription that provokes 0x0020 is FA5 scope. FA3 sends no 0x001F.

So the script names a trigger the campaign deliberately disconnected, and then instructs the user to file a defect when it fails to work. Either drop the trigger entirely and state plainly that the blocks are expected to stay hidden for the whole of FA3 (the honest shell-slice expectation), or replace it with the only real path (a server-side allegiance change that makes ACE push 0x0020 unsolicited) and say so. The "What to report" bullet must go with it.

---

SHOULD-FIX

SF-1 — the F3/F4 "retail Toggle-action semantics" claim has no retail anchor (item 2)

src/AcDream.App/UI/Layout/SocialPanelController.cs:200-204:

"lets RetailUiRuntime.HandleInputAction implement retail's Toggle-action close-on-second-press semantics (same shape as OpenSpellbook's own page-aware toggle)"

I went looking for the retail handler and could not find one. Re-derived:

• No P0x57 consumer exists in the binary. The only two 0x57 reads anywhere in acclient_2013_pseudo_c.txt are AppraisalProfile::InqInt(arg2, 0x57, …) @004b2954 and AppraisalProfile::InqFloat @004b3981 — unrelated. No GetAttribute_Enum(this, 0x57, …) site exists. This matches lane A §6.1's UNVERIFIED flag; the FA3 class doc correctly restates it for the root's P0x57, then quietly relies on a different retail claim for the toggle.
• ClientUISystem::OnAction @0x00564B90 does not handle these actions. For m_InputAction > 0x7c it handles exactly 0x1000001E, 0x10000025 and 0x1000002B and returns 0 for everything else — 0x1000000E/0x1000000F fall through.
• gmPanelUI never sees the action. gmPanelUI::PostInit @0x004BD010 does RegisterForGlobalMessage(this, 1), but gmPanelUI::ListenToGlobalMessage is COMDAT-folded onto NoticeHandler::RecvNotice_DisplayWeenieError @0x004F5860, whose body is return;.
• No other OnAction implementation's range covers 0x1000000E/0x1000000F (ChatInterface 0x10000020..0x10000119, magic 0x10000060..0x10000105, combat 0x1000005B.., CPlayerSystem 0x1000002A..).

So retail's actual F3/F4 behaviour — and in particular what a repeat press does when the panel is already open on the other tab — is not established from this decomp. The shipped rule ("close only when already on the target tab") is acdream's own OpenSpellbook precedent, which is a perfectly defensible choice; it just must not be labelled as retail's. Re-word the comment to name it as precedent-following, and add the unknown to the research doc's §8 list (next to U7, which is the same gap) so FA7's closeout can decide whether it wants a register row. The gate script's "same toggle-closes-on-repeat-press shape as every other Toggle*Panel action" (:26-29) is fine as-is — it claims acdream consistency, not retail fidelity.

SF-2 — per-frame closure allocation in the allegiance page tick

src/AcDream.App/UI/Layout/SocialAllegiancePageController.cs:108-110:

IReadOnlyList<UiText.Line> lines = hasProfile ? NoLines : BlankLine;
if (_monarchName is not null) _monarchName.LinesProvider = () => lines;
if (_patronName is not null) _patronName.LinesProvider = () => lines;

lines is captured, so this allocates a display class plus a delegate, twice, on every frame, whether or not the panel is visible (RetailUiRuntime.cs:559 ticks it unconditionally). At the profile's measured ~520 FPS that is ~2,000 allocations/second of pure garbage for a value that changes at most once per session. The Modern Runtime slices spent whole commits driving per-frame paths to 0 B; this is a new, avoidable regression of that discipline in the graphical hot loop.

Fix: hoist two static readonly Func<IReadOnlyList<UiText.Line>> fields (one returning BlankLine, one returning NoLines) and assign the cached delegate, and/or only write LinesProvider when the gate actually flips. The fellowship page's tick is already allocation-free — this is the only offender.

SF-3 — the live-mount probe prints two of its headline findings without asserting them (item 7)

tests/AcDream.App.Tests/UI/Layout/SocialPanelLiveMountProbeTests.cs:117-118 computes passupCount and prints it, but never asserts it. The commit message nevertheless claims "0x10000492 is confirmed authored twice under the allegiance page". A print is not a gate: this cannot fail if a future importer change collapses or drops one of the two instances — which is exactly the regression the scoped-lookup rule exists to survive. (For the record I did confirm the fact independently: the fixture authors 0x10000492 twice, once under 0x10000255/0x10000490 and once under 0x1000025A/0x10000490, and the probe printed = 2.) Add Assert.Equal(2, passupCount).

Likewise, the probe activates the tab behavior (:67) and asserts UnresolvedEntries is empty, but never asserts page exclusivity — that after ActivateTabBehavior() exactly one of the four page elements is Visible, and that it is the Allegiance page. That is the #372 class ("the panel mounts but the pages are wrong/blank") stated as an assertion rather than a hope, and it is one line.

Everything else the probe asserts is real and does cover the classes it claims: non-empty tab captions (the #375 resolver class — I re-ran it and it passes), the four pages resolving, the fellowship frame pair, and the six allegiance signature elements. All pass against the installed DATs.

SF-4 — "all three visible option checkboxes" is four

src/AcDream.App/UI/Layout/SocialFellowshipPageController.cs:19. Frame 0x1000026B authors four Type 0x10000035 children — 0x10000270 (IgnoreFellowshipRequests), 0x10000271 (FellowshipAutoAcceptRequests), 0x10000272 (FellowshipShareXP), 0x10000273 (FellowshipShareLoot) — per lane A §3.1 and confirmed in the fixture. The gate script step 11 (:73-82) hedges with "a fourth, Share Loot, may also be present" when both the decomp and the committed fixture already settle it. Fix the count in both places; a gate script that is unsure about what the user will see invites noise.

SF-5 — AD-79's pinning test does not cover the control AD-79 itself enumerates

The register row names seven controls, including the Friends page's "Appear Offline"-shaped checkbox 0x1000052C, and cites SocialPanelControllerTests.FriendsAndSquelchActionButtons_AreClickable_ButHaveNoHandler as what pins the INERT contract. That test (SocialPanelControllerTests.cs:272-291) covers only the six buttons. 0x1000052C builds through DatWidgetFactory.BuildCheckbox as a UiButton (DatWidgetFactory.cs:785-816), so it can be added to the existing loop verbatim. Seven enumerated, six pinned is the kind of drift AD-78's own "Risk" column warns about.

SF-6 — the two page controllers do not cite AD-79 by id

SocialFriendsPageController.cs:23-25 and SocialSquelchPageController.cs:21-22 both say "See this commit's single register row…". AD-79's own Where column asserts "both classes' own doc comments cite this row". Literally true, practically not: a future reader grepping AD-79 will not find the code. Name the row.

SF-7 — the allegiance empty state is coarser than the contract's own source (item 4)

FA3's contract line is "all four pages' empty states", and lane A §4.5 is what defines the allegiance one. I re-read and byte-verified that section's claims because it is what the slice implements against:

• gmAllegianceUI::UpdateMonarchData @0x00491B40 branches on (monarchId == player_id || monarchId == 0) — retail hides the monarch block when there is no monarch or the monarch is you, then sets both m_pMonarchName and m_pMonarchFollowers to the literal at data_794358.
• data_794358 byte-verified in the PDB-paired binary (C:\Users\erikn\Downloads\acclient.exe, image base 0x400000, RVA 0x394358 → file offset 0x394358): bytes 20 00 00 00 = UTF-16LE " ", one character. So lane A's L" " reading is correct and FA3's BlankLine = [new UiText.Line(" ", …)] (SocialAllegiancePageController.cs:40-41) matches it exactly — a single space, not an empty string, as asserted at SocialPanelControllerTests.cs:177-178. This half is clean.

What is coarser: FA3 gates both blocks on Snapshot.HasProfile rather than per-relationship. The consequence is not hypothetical — the moment any 0x0020 AllegianceUpdate lands, a monarch character sees an empty, visible monarch block that retail hides, and anyone whose patron is the monarch sees an empty patron block instead of retail's relabelled-monarch presentation. FA2 already ships the data needed to do it properly: IRuntimeAllegianceView.TryGetMonarch / TryGetPatron (GameRuntimeGameplayViews.cs:200-204) plus Snapshot.MonarchGuid; the FA3 Callbacks record deliberately narrows the input to Func<RuntimeAllegianceSnapshot> (SocialPanelController.cs:90-96), which is what forecloses it.

I am not calling this a MUST-FIX: FA3 is a shell slice, the class doc is honest about the simplification, and MF-2's finding means HasProfile is effectively always false for the whole FA3 gate, so nothing wrong is visible during this gate. But it is a contract gap that will be invisible by the time FA5 lands unless it is written down. Either widen the callback to the view and implement the real per-relationship gate now, or add an explicit FA5 acceptance line ("the monarch block hides when the monarch is you; the patron block hides when the patron is the monarch") to the plan's FA5 row so it cannot be lost.

Related, and worth a line in the class doc: Tick() reassigns LinesProvider unconditionally every frame, so any FA5 code that sets a real monarch/patron name on 0x10000257/0x1000025C will be overwritten on the next frame unless this method is changed at the same time.

SF-8 — Tick() ignores _disposed

SocialPanelController.Dispose() (:224-228) sets _disposed and nothing reads it. The handle passes Controller = controller to RetailWindowFrame.Mount, and RetailUiRuntime.SocialPanelController is never nulled, so RetailUiRuntime.Tick's SocialPanelController?.Tick() (RetailUiRuntime.cs:559) will keep ticking the four page controllers after disposal. Nothing throws today (the Runtime owners outlive the panel and the J-owner snapshot getters are disposed-guarded), so this is low severity — but "tick a disposed controller" is precisely the class the J-slices spent commits eliminating. One if (_disposed) return; closes it.

SF-9 — SocialPanelRowText.FindDeepest documents a stronger guarantee than it implements

SocialPanelRowText.cs:19-31 promises "the deepest UiText descendant (pre-order, last match wins)". The implementation returns the last match in traversal order, which equals the deepest only when the subtree is a single chain. Both real templates are single chains — I dumped them from the installed DATs:

FriendsRow  0x10000519 Type 3 (270x24) -> 0x1000051A Type 0xC -> 0x1000051F Type 0xC
SquelchRow  0x10000541 Type 3 (270x24) -> 0x10000542 Type 0xC -> 0x1000054D Type 0xC

so the behaviour is correct today and the class doc's honesty about gmFriendsUI/gmSquelchUI being outside the campaign's decompiled scope is exactly the right posture. Just make the doc describe what the code does, or make the code track depth.

---

2. What verified clean

Stated plainly, because most of this slice is right.

The tab-table correction (item 1). Confirmed three independent ways (§1 above). The addendum in d7e1cffd is accurate, and correcting in place while leaving the original text visible follows the FA1/FA2 convention.

§6 Campaign-OP lessons compliance (item 3). Each one re-derived:

• String resolver on every Build. MountSocialPanel passes resolver.Resolve to the main LayoutImporter.Build (RetailUiRuntime.cs:2611-2617) and its nested TemplateResolver builds each row template with its own strings.Resolve (:2626-2645). Both covered — the #375 class. The probe's non-empty-caption assertion is the live check, and it passes.
• Scoped FindDescendant for every repeating id. I enumerated all duplicate element ids in the panel subtree rather than trusting the stated one. Duplicates exist at 0x10000439/0x100000E9/0x10000215 (×4, tab button art), 0x100002CE–0x100002D0 (×16, button 3-slice art), 0x10000328 (×6, checkbox art), 0x00000001/0x10000071/0x10000072/ 0x10000364–0x10000366 (×4, scrollbar parts), 0x10000490/0x10000491/ 0x10000492 (×2, the two allegiance blocks), and — not previously called out anywhere — 0x10000254, 0x1000025D and 0x1000051E repeat ACROSS pages (0x10000254 under both the Friends page and the allegiance monarch block; 0x1000025D under the Friends page and the patron block; 0x1000051E under both Friends and Squelch). Every FA3 lookup is safe: the four page ids, the two fellowship frames, both allegiance field containers, both name texts and both ListBox ids are each unique, the per-page controllers scope to their page root anyway, and the single flat layout.FindElement(0x10000290) for the close button targets a unique id. 0x10000492 is not looked up at all in FA3, so the intra-panel duplication cannot bite yet — but the three cross-page duplicates above are worth carrying into FA5's notes, since FA5 will be resolving allegiance-page ids.
• Tab activation performed. controller.ActivateTabs() at RetailUiRuntime.cs:2662, after Bind — the OP3 ordering constraint. Verified live: UnresolvedEntries is empty and IsShowingAllegiance is true after activation.
• No lazily-created fill-anchored 0×0 children (the #372 class). The new controllers create no elements at all. The only lazy child is UiTemplateListBox's viewport, which already seeds Width/Height from the ListBox's authored extent (UiTemplateListBox.cs:152-182, the #372 fix), and both social ListBoxes carry real authored extents (Friends 270x400, Squelch 270x430) at Bind time.
• Same-layout template-prototype skip. Checked for this layout specifically: all four P0x64 arrays point at other LayoutDescs — Friends 0x2100005D/0x10000519, Squelch 0x21000060/0x10000541, fellows 0x21000030/0x10000281, vassals 0x2100002F/0x10000266. The importer's skip is same-LAYOUT only (LayoutImporter.cs:233-249), and in any case MountSocialPanel uses the single-root ImportInfos(dats, layoutId, rootElementId) overload, which never enumerates top-level siblings. No parked prototypes are possible here.
• No hand-rolled scroll viewport. Both lists ride the existing UiScrollablePanel through UiTemplateListBox, so the #371 straddling-row clip comes for free. Popup/pointer-priority rules are not applicable.

UiTemplateListBox.Flush(). The doc claim "resetting ContentHeight to 0" is accurate: UiScrollablePanel.ClearContent() (:54-61) removes every child, clears _baseTops, sets ContentHeight = 0 and resets the scroll offset. The dormancy guard (_viewport?.) is genuine — a never-populated box still never allocates its viewport. The shrink case the Friends/Squelch rebuild needs therefore works.

Fellowship empty-state frame swap (item 4). Retail anchor re-read at gmFellowshipUI::Update @0x0048F440: when ClientFellowshipSystem::GetFellowshipSystem()->m_pFellowship == 0 it calls m_pInAFellowshipFrame->SetVisible(0) then m_pNotInAFellowshipFrame->SetVisible(1) — exactly the two writes SocialFellowshipPageController.Tick makes, driven off RuntimeFellowshipSnapshot.IsInFellowship. Lane-A unknown U6 is genuinely closed: page 0x10000292 has exactly two children, the two frames, so a single Visible toggle per frame really is the whole swap. (Frame contents: 0x1000026B = name box 0x1000026F, Create 0x10000274, four checkboxes; 0x10000275 = roster ListBox 0x10000279, scrollbar, six buttons 0x1000027B–0x10000280.)

Friends/Squelch read-only binding (item 5). Bound to the J4.1 owners by reference — RuntimeCommunicationState.Friends/.Squelch are get-only properties constructed once (RuntimeCommunicationState.cs:67-68,132-133) and cleared in place at reset (:250-251), so holding the instance across a generation reset is correct, and FriendsState.Clear() bumps Revision (FriendsState.cs:67-74) so the panel rebuilds to empty on its own. No new state copies; Snapshot()'s array copy only runs on a revision change. The per-frame cost when nothing changed is one Interlocked.Read per list. The D1 INERT contract holds: checkboxes build as UiButton with a null OnClick (no latching visual state without a handler), and the six buttons are pinned null by test.

Panel exclusivity + catalog (item 6). SocialPanel = 12 is byte-verified (root P0x10000029 = 12). Registered in Mounted only. The toolbar seam genuinely tolerates it: SyncToolbarWindowButtons iterates ToolbarPanels only (RetailUiRuntime.cs:809-814), so no phantom button; BindPanelButtons binds by authored toolbar element, and the toolbar authors no 0x10000029 = 12 button; and the one path that does reach the toolbar with a non-toolbar id — OnWindowVisibilityChanged → ToolbarController.SetPanelOpen(12, …) (:831-832) — walks _panelButtons, finds nothing, and returns (ToolbarController.cs:394-406). This is the same path PositiveEffects (4), LinkStatus (8), MiniGame (9) and Vitae (15) already take. No crash, no greyed phantom. Both open paths keep RetailPanelUiController state coherent: ToggleWindow and CloseWindow both route through TryGetPanelId → _panelUi (:708-711, :801-807).

Window-frame policy. RetailWindowFrame.Options for the social panel is byte-for-byte the Options panel's post-review policy (ResizeX=false, bottom-edge-only, both constrain flags, full ContentAnchors, DrawChromeCenter = !AuthorsFullPanelCenter(rootInfo)), differing only in Left/Top. No invented divergence in the shared main-panel cohort. The root/page height mismatch (root 300x362, pages 300x575) is identical to the already-gated Options panel's own authored shape, so it is not an FA3 property.

The live-mount probe run (item 7). Executed with ACDREAM_PROBE_LIVE_MOUNT=1 against the installed DATs: 1 passed, 0 failed. Every assertion holds. Given #383 (installed-DAT vs committed-fixture drift), I also cross-checked the committed social-panel fixture against the probe's live dump on root extent, child count and order, the tab table, all four page P0x57 values, and both allegiance blocks' geometry (including the two differently sized 0x10000490 instances, monarch (210,0 90x36) vs patron (220,0 80x36)). No drift — this fixture is faithful to the installed DAT.

Tests. SocialPanelControllerTests + RetailPanelCatalogTests: 22 passed. Full AcDream.App.Tests on the committed Release binaries: 4,871 passed / 3 skipped / 0 failed — no collateral regressions. The ledger's +18 arithmetic checks out exactly (13 SocialPanelControllerTests + 4 RetailPanelCatalogTests

• 1 probe). I did not re-run the full 13,233-test solution suite (no builds permitted in this review), so that figure is unverified but arithmetically consistent.

Register bookkeeping. AD-79's header count is right — the table contains exactly 59 AD- rows, matching "59 active rows", up one from 58. The row's element enumeration is accurate against the fixture (Friends 0x10000514/ 0x10000515/0x10000516 + 0x1000052C; Squelch 0x10000547/0x1000054B/ 0x1000054C), and its honesty about gmFriendsUI/gmSquelchUI being outside the campaign's researched scope is the right framing. Only SF-5/SF-6 above.

Gate-script spot checks (item 8). Steps 1–3 (F3 opens on Allegiance; repeat F3 closes; F4 opens directly on Fellowship), step 4 (F3 while open on Fellowship switches rather than closes) and step 5 (the authored X at 0x10000290, a direct root child at (276,0) 24x25, always visible because it is not inside any page, wired to ToggleWindow) all match RetailUiRuntime.OpenSocialPanel (:603-620) and SocialPanelController.Bind's close wiring (:145-150) exactly. Steps 7–8's exclusivity claims match RetailPanelUiController.SetPanelVisibility's one-active-panel logic. Step 6's geometry claims match the frame options. The two claims that do not hold are MF-1 and MF-2. One wording nit for whoever edits the script: step 5 calls the X "top-right of the window chrome" when it is an authored panel element, not chrome — harmless, but a user hunting the chrome's own close affordance may be briefly confused.

---

3. Disposition

APPROVE-WITH-FIXES. MF-1 and MF-2 must land before the user runs the gate — both are in docs/research/2026-08-12-campaign-fa-test-script.md and neither touches code. SF-1 through SF-9 are code/doc/test corrections that can ride the same fix round. Nothing here warrants a re-review of the mount path itself: the tab table, the frame swap, the string resolver, the scoped lookups, the tab activation, the catalog registration and the toolbar seam are all correct, and the live-mount probe passes against the installed DATs.