acdream/docs/research/2026-08-12-campaign-fa-test-script.md

Campaign FA connected-gate test script

Status: FA3 owes its connected gate; FA4 (below) owes its own. Launch with ACDREAM_LIVE=1 against the local ACE server (testaccount / +Acdream). Anything marked INERT is authored and clickable but deliberately does nothing yet — that is the correct, contracted behavior for this slice (D1), not a bug.

FA3 is the panel SHELL only: mount, F3/F4 open paths, tab switching, all four pages' empty states, and Friends/Squelch read-only lists. Fellowship roster rows, the create-fellowship dialog, live vitals, and every Allegiance swear/break/kick action are FA4/FA5 scope — do not report their absence here.

FA4 makes the Fellowship page fully live (§FA4 below): roster rows, the 0x00A6 panel-open/vitals-stream gate, the create flow, member actions + confirmations, the four option checkboxes, and the open/close caption swap. Honest limitation up front: several FA4 steps need a SECOND character (recruit, the inbound invite dialog, watching another member's vitals update). If a second ACE account/character is not available for this gate, run every step marked [SOLO] and defer the steps marked [TWO-CLIENT] to Campaign FA slice FA6's bot-vs-ACE gate (docs/plans/2026-08-11-fellowship-allegiance-campaign.md, D8) — do not treat an unrun two-client step as a failure.

---

FA3 — the social panel shell

Opening the panel — F3/F4, keyboard only

1. Press F3. The social panel opens on its Allegiance tab (the authored default tab — Allegiance is ALSO the left-most tab drawn on the tab strip, at x=0; the default tab and the left-most tab are the SAME tab, verified by re-deriving the authored tab table directly from the fixture, the live-mount probe, and each page's own P0x57 action-map id — see SocialPanelController's class doc for the full citation. [FA3 fix-round correction, mechanism MF-1] an earlier draft of this script claimed Friends was drawn left-most; that was wrong). No toolbar button opens this panel — retail authors none (lane A §6.1) — so there is nothing to click for this step besides the keybind itself.
2. Press F3 again while the panel is open and already on the Allegiance tab. The panel closes — same toggle-closes-on-repeat-press shape as every other Toggle*Panel action (e.g. F11/Options, Spellbook).
3. Press F4. The social panel opens directly on its Fellowship tab (F4 switches AND opens in one press, even if the panel was closed).
4. With the panel open on Fellowship, press F3. The panel does NOT close — it switches to the Allegiance tab (F3 is scoped to its own tab, not a blanket close). Symmetrically, pressing F4 while open on Allegiance switches to Fellowship rather than closing.
5. Click the panel's own close (X) button, top-right of the window chrome. The panel closes — same action as a repeat F3/F4 press on the already-active tab.
6. Drag the window by its border/chrome; resize it from the BOTTOM edge only. Same shared gmPanelUI geometry policy as every sibling main panel (Options, Character, Inventory, Spellbook, the indicator-detail panels): draggable, resizable from the bottom edge only, remembers its height across a close/reopen within the session.

Exclusivity vs sibling panels

7. Open Character Info (or Inventory, or Options), then press F3. The other panel closes and the social panel opens on Allegiance — the SAME retail gmPanelUI one-active-panel-at-a-time behavior every sibling panel already has (RetailPanelUiController.RegisterMainPanel shares one geometry rectangle across all ten registered main panels).
8. With the social panel open, open Character Info. The social panel closes. Confirms the exclusivity is bidirectional, not just "opening the social panel closes others."

Tab switching

9. Click each of the four tabs (left-to-right authored order: Allegiance, Fellowship, Friends, Squelch — only ONE tab is highlighted "open" at a time. [FA3 fix-round correction, mechanism MF-1] an earlier draft of this script had the order as Friends/Allegiance/Fellowship/Squelch; that was wrong — re-derived directly from the fixture's authored 0x2E tab table). Each switches the visible page; exactly one page is visible at a time. No crash, no stuck state, switching back and forth repeatedly is safe.
10. Note the tab captions read correctly, in this left-to-right order — "Allegiance", "Fellowship", "Friends", "Squelch" — not blank. A blank caption on any tab button would be the #375 missing-string- resolver class of bug; report it immediately if seen.

Fellowship page — empty state

11. On a character with NO fellowship (the default state), open the Fellowship tab. Expect: an editable fellowship-name text field, a Create Fellowship button, and FOUR checkboxes (Ignore Fellowship Requests / Auto-Accept Requests / Share XP / Share Loot — [FA3 fix-round correction, mechanism SF-4] an earlier draft hedged this as "three... a fourth may also be present"; the fixture and the decomp both settle it at four). No member list, no leader/quit/open/recruit/dismiss/disband buttons visible — those belong to the OTHER (in-fellowship) frame, which is hidden. [FA4 correction] the Create Fellowship button, the name field, and the four checkboxes are now LIVE, not inert — see §FA4 below for their full behavior; this step's own scope is only the frame/control PRESENCE, still correct as written.
12. If the test character IS currently in a fellowship (uncommon for +Acdream's default state, but possible if a prior session left one active, or if you ran §FA4's Create step below), open the Fellowship tab instead expecting: a fellowship name display, a member roster ListBox, and six buttons (Leader/Quit/Open/Recruit/Dismiss/Disband). [FA4 correction] all six buttons are now LIVE — see §FA4.

Allegiance page — empty state

13. On a character with NO allegiance profile ever received this session (the default state — nothing has queried allegiance data yet), open the Allegiance tab. Expect: the monarch block and patron block BOTH HIDDEN (no visible "Monarch:" / "Patron:" labels or name lines), while your own character line (name/followers/rank) and the vassal list area remain visible per their authored layout. The Swear/Break/Kick buttons and the "Ignore Allegiance Requests" checkbox are present and INERT.
14. This state does NOT change for the rest of this gate — that is the correct, contracted FA3 behavior, not a bug. [FA3 fix-round correction, mechanism MF-2] an earlier draft of this script sent you to @allegiance info expecting it to make the blocks visible, and told you to report it if that didn't happen. That trigger CANNOT fire and the instruction was wrong: FA3 never sends the 0x001F AllegianceUpdateRequest subscription (FA5 scope, per the plan's corrected D6/CF-1 note), and 0x0020 AllegianceUpdate — the ONLY inbound message that can populate this panel's data — is never provoked by anything FA3 does. Running @allegiance info in chat still works exactly as before FA3 (it is an independent, already- shipped command) and WILL print your monarch/patron/vassal data as chat TEXT — but its response (0x027C) stopped seeding this panel's profile back in FA2 (4272ad0e), so it has zero effect on this page. The correct, expected combination for this entire gate is: @allegiance info prints real data to the chat window (if you have an allegiance), AND the Allegiance page's monarch/patron blocks stay hidden throughout — report NEITHER half as a bug. The panel blocks becoming visible at any point during this gate (see "What to report" below) is the actual anomaly to watch for.

Friends page — read-only list

15. Open the Friends tab. If the test account has any friends server-side, their NAMES appear as rows in the list (no online/ offline styling, no icons — names only, this slice's explicit scope). If the account has none, the list is empty (no placeholder text is invented).
16. The three action-shaped buttons and the "Appear Offline"-shaped checkbox are INERT — clicking/toggling them does nothing (register row AD-79). This is CONTRACTED for FA3; do not report it.

Squelch page — read-only list

17. Open the Squelch tab. If the test account has any squelched characters or accounts, their names appear as rows (characters and account-level squelches both listed, names only). Empty otherwise.
18. The three action-shaped buttons are INERT (register row AD-79, same as Friends). CONTRACTED, do not report.

Scrolling a long roster

[FA3 fix-round addition, blast N-8/MF-1] the two ListBoxes' own scrollbars were unwired until this fix round — completely unreachable past the visible extent, not merely awkward to use. This step exercises the fix directly.

19. If the test account's Friends or Squelch roster is longer than fits in the panel's visible area (the Friends box is 270×400 but the panel itself is only ~300×362, so as few as a dozen or so entries can already overflow — check either tab), drag the scrollbar thumb (or click the track/arrows) and confirm the rows scroll and every name remains reachable, all the way to the last row. This is a soft check if the test account's roster is genuinely too short to overflow — do not manufacture a long roster just to exercise this step, but if the roster IS long enough, a scrollbar that does not move the list, or a list that will not scroll at all, IS a bug — report it.

Live update while the panel is closed

20. This is a soft check, not required to pass/fail the gate: if Friends/Squelch state changes server-side while the social panel is CLOSED (e.g. via @friend chat commands, if any are wired), then reopening the panel afterward should show the up-to-date list immediately (the read-only binding polls every frame WHILE THE PANEL IS VISIBLE — [FA3 fix-round correction, blast SF-2] an earlier draft of this script said the poll runs "regardless of which tab or window is visible"; that changed in the fix round — the rebuild is now gated on the social panel's own visibility so it does no DAT work while closed, but it still catches up in full the moment the panel is shown again, so the user-visible outcome described here is unchanged. See SocialFriendsPageController/ SocialSquelchPageController's own doc comments). Report if the list is stale on reopen.

Window restore-open behavior across relaunch

[FA3 fix-round addition, blast N-8] stated honestly rather than left untested: the social panel is NOT in acdream's short list of windows whose OPEN/CLOSED state is force-reset every session (stateManagedVisibilityWindows — Combat/JumpPowerbar/ ExternalContainer/Vendor). This is a deliberate, documented choice (the FA seams doc), and it matches the EXACT SAME convention every sibling main panel already uses — Options, Spellbook, Character, Inventory, and Vitae all restore their own last open/closed state too.

21. Open the social panel (F3 or F4), then close the client and relaunch (or simply log out and back in without closing the window). The EXPECTED, non-bug behavior is that the social panel reopens automatically in whatever tab/open state it was left in — the SAME restore-open behavior every other main panel already has. This is not something to report; it is only listed here so the behavior is understood in advance rather than surprising anyone mid-gate.

---

What to report

• Any tab caption that renders blank instead of its retail name.
• The panel opening on the wrong DEFAULT tab (should be Allegiance, and Allegiance is also the left-most tab) on a fresh F3 press with the panel previously closed.
• F3/F4 failing to switch tabs while the panel is already open, or closing the panel when it should only switch tabs.
• The panel NOT closing/opening exclusively with sibling gmPanelUI panels (Character/Inventory/Options/etc.).
• The Fellowship page showing the WRONG frame for the character's actual fellowship state (e.g. showing the roster/six-button frame while +Acdream has no fellowship).
• The Allegiance page's monarch/patron blocks becoming VISIBLE at ANY point during this gate — there is no code path in FA3 that can make that happen (see step 14); if it happens, that is a real bug (an accidental wire connection), not the false-defect trigger an earlier draft of this script pointed at.
• Any INERT button/checkbox producing a VISIBLE effect (a Create Fellowship, Swear, Friends, or Squelch action that unexpectedly does something) — this would mean either an accidental wire connection or a stale INERT claim in this script.
• A Friends/Squelch row showing anything other than a plain name (an exception, a blank row, garbled text).
• A Friends/Squelch scrollbar that does not move the list, or a longer-than-visible roster with no way to reach its later rows (step 19) — only when the test account's roster is actually long enough to overflow.
• Any crash, hang, or exception in the log while opening/closing/ switching tabs repeatedly.

Explicitly NOT in scope for this gate

• Allegiance monarch/patron/vassal LIVE population, swear/break/kick wire sends, and their confirmation dialogs (FA5).
• Friends/Squelch add/remove/appear-offline/clear wire sends (D1 — out of campaign scope entirely, register row AD-79).
• The bot-vs-ACE two-session fellowship gate (FA6).

---

FA4 — the Fellowship page fully live

Prerequisite: open the Fellowship tab (F4, or click it from the already-open panel). All step numbers below restart at 1 for this section's own numbering.

Create (name + shareXP) — [SOLO]

1. With no fellowship, type a name into the fellowship-name field and watch the Create Fellowship button. It is DISABLED while the field is empty/whitespace-only and ENABLES the instant you type a non-blank character — this IS retail's refusal mechanism (lane B §2.2: the button itself is the guard; there is no separate error message to expect).
2. Before clicking Create, toggle the "Share Fellowship Experience and Luminance" checkbox (on or off — your choice) and note its state.
3. Click Create Fellowship. The panel switches from the empty-state frame to the populated frame: your fellowship's name appears, you appear as the sole roster row (with your own name, level, and vitals bars), and the six member-action buttons appear. [fix-round SF-7 correction: the previous wording here contradicted itself — "only Quit" followed by "Disband and Open should ALSO be enabled" — which would prime a tester to report correct behavior as a defect.] Quit, Disband, AND Open should ALL be enabled (you're the leader of a real fellowship now); Leader and Dismiss stay DISABLED because no other member is selected yet (see "button states" below).
4. Check the ACE server confirms ShareXP matches what the checkbox said at the moment you clicked Create (a chat command like @fellow status, or simply trusting the wire — this is a soft check, not required to fail the gate over).

Roster with a second character — [TWO-CLIENT] (bot alternative: FA6)

5. Recruit a second character into the fellowship: log a second ACE account/character into a separate acdream (or retail) client, select them in the world (click them), then click Recruit on the first client. If accepted (see the invite steps below), the second character appears as a NEW roster row on the first client — confirm their name, level, and vitals bars render (not blank, not a crash).
6. With two members in the fellowship, scroll the roster if it overflows the visible area and confirm both rows remain reachable (same scrollbar mechanism FA3 already gated, UiTemplateListBox).

Vitals updating while the panel is open AND the frozen-roster

behavior when closed — [TWO-CLIENT], the 0x00A6 gate made observable

7. With the Fellowship tab open and a second member in the fellowship, have that second character take damage or use stamina/mana (attack a monster, cast a spell, etc.). Their health/stamina/mana bars on the FIRST client's roster should update within a second or two — this is the vitals stream D4 turns on (0x00A6 panel-open declaration gates ACE's 0x02C0 sends, lane B §4.5).
8. Close the social panel (or switch to a different tab), have the second character take more damage, then reopen the Fellowship tab. EXPECTED: the roster shows the LAST vitals it had before the panel closed (frozen), then updates live again within a second or two of reopening — this is the direct, observable consequence of 0x00A6 being sent false on hide and true on show. A roster that keeps updating in real time WHILE THE PANEL IS CLOSED would mean D4 is not actually gating anything — report that as a bug.
9. [fix-round MUST-FIX 3, new step] Reconnect while the Fellowship page is left open. With the Fellowship tab open and a fellowship active, force a disconnect/reconnect (kill the ACE connection, or use whatever local reconnect trigger is available) WITHOUT closing the social panel or switching tabs. Once the client re-enters the world on the new session, confirm fellow vitals resume updating (repeat step 7's damage-and-watch check). EXPECTED: vitals update normally on the new session, exactly as before the reconnect. BUG if vitals stay frozen for the rest of the new session — that means 0x00A6 was never re-declared after the generation reset (SocialPanelController.ResetSessionDeclaration).
10. Your OWN row's vitals should always update (your own vitals are driven by the existing player-vitals pipeline, not the fellowship 0x02C0 stream) — this is expected and not a sign that 0x00A6 is failing to gate the OTHER member's stream.

Recruit/dismiss/quit/disband/leader flows with their confirmations

11. [SOLO, self only] With a solo (1-member) fellowship you lead, click Quit. You leave the fellowship (no confirmation dialog for Quit — retail has none, lane B §2.5) and the panel reverts to the empty-state frame.
12. [SOLO, self only] Create another fellowship, then click Disband instead. Same visible outcome (empty-state frame) via the wire's disband=true flag — no confirmation dialog either.
13. [TWO-CLIENT] With two members, select the OTHER member's roster row (click their name) and click Dismiss. They are removed from the roster; their own client sees themselves leave the fellowship.
14. [TWO-CLIENT] With two members, select the other member's row and click Leader (Assign Leadership). The LeaderGuid changes — confirm via the leader's name tinting gold in the roster (this controller's own visual cue — lane A's row template has no dedicated leader marker, see SocialFellowshipPageController's class doc, register row AD-82) — and confirm the enable/disable states flip: the OLD leader's Disband/Open buttons should now be DISABLED, the NEW leader's (on their own client) should now be ENABLED.
15. [TWO-CLIENT, the leader-handoff rule] As the CURRENT leader of a 2+-member fellowship, click Quit (not Disband). EXPECTED: leadership transfers to the other member FIRST (their client should briefly show themselves as leader), THEN you leave — this is retail's pre-quit leader hand-off (lane B §2.5/§3.6, already ported in RuntimeFellowshipState.RequiresLeaderHandoffBeforeQuit). Report if the fellowship is left leaderless or the WRONG member becomes leader.
16. [fix-round MUST-FIX 4, new step] Select a fellow in the WORLD (click their 3D model), not their panel row. EXPECTED: Dismiss and Assign-Leader enable exactly as if you had clicked their panel row, and their row shows the panel's own selection highlight — retail's gmFellowshipUI::UpdateFellowSelection reverse-selection arm (world click selects the panel row too), reproduced against acdream's own guid-keyed row tracking rather than a ported generic ListBox selection model (register row AD-82).

The open-toggle caption swap — [SOLO]

17. With a fellowship active, note the Open/Close button's caption. A CLOSED fellowship shows "Open"; click it and it should flip to show "Close" IMMEDIATELY on click, not after a delay (retail's button reads as the ACTION available, not the current state, and pre-toggles its own state before the server echo — lane A §4.1, fix-round NIT N-0). Click again to flip back.
18. The Open/Close button is enabled only when you are the leader — confirm it is disabled (greyed / unclickable) if you are a member but not the leader (needs a second client to observe from the non-leader side).

The invite dialog — [TWO-CLIENT]

[fix-round MUST-FIX 2 correction, 2026-08-12: the OLD steps 18/19 here tested whether acdream's CLIENT gates the invite dialog on the Ignore/AutoAccept option bits. That mechanism never existed in retail and has been deleted from acdream (D6's correction) — retail's client shows the confirmation dialog UNCONDITIONALLY for every request it receives; ACE alone decides whether to send one at all, by filtering server-side. The steps below test the CORRECTED behavior: the dialog always shows regardless of the SECOND client's own checkbox state. If your local ACE build implements the server-side filter (lane B: refuses the recruiter outright when the target has Ignore set; auto-joins without a confirmation when the target has AutoAccept set), you will observe the FIRST client's Recruit failing/auto-succeeding with NO dialog ever reaching the second client at all — that is ACE's behavior, not a client bug, and is out of scope for this gate either way.]

19. Baseline: on the SECOND client, ensure both "Ignore Fellowship Requests" and "Automatically Accept Fellowship Requests" are UNCHECKED (Character tab or this page's own checkboxes — either surface, they're the same value). From the FIRST client (in a fellowship, as leader or with Recruit rights), select the second character in the world and click Recruit. The SECOND client should show a confirmation dialog asking to join the fellowship, with the server's message text rendered VERBATIM (no added "Continue?" suffix — type 4 is not in the 2/3/5/6 suffix set). Accept it — the second character joins, appears on the first client's roster.
20. Repeat with "Ignore Fellowship Requests" CHECKED on the second client (the FIX ROUND's regression check — this is the DEFAULT state for a character who has never touched the option). EXPECTED: the dialog STILL shows on the second client exactly as in step 19 (assuming your local ACE does not itself refuse the recruit server-side first) — the second character's OWN checkbox state must NOT silently swallow the invite with no dialog and no chat line. If it does, that is the exact regression MUST-FIX 2 exists to prevent.
21. Repeat with "Automatically Accept Fellowship Requests" CHECKED on the second client (and Ignore unchecked — the two are mutually exclusive; checking one should auto-uncheck the other, confirm that too). Same expectation as step 20: the dialog still shows on the client (acdream no longer auto-responds on its behalf); if your local ACE implements the auto-accept-without-confirmation server-side behavior, you may instead see the character join immediately with no dialog — that is ACE's mechanism, not this client's.
22. Reject an invite (baseline state, dialog showing): click Reject instead of Accept. The second character does NOT join; no crash or stuck dialog state on either client.

Share-column expectations vs ACE — [SOLO, low member counts]

23. With a solo (1-member) fellowship, Share XP checked, the stats text should read a percentage of 100% (the even-split table's first entry, lane B §7.2). With 2+ members (if a second client is available) sharing evenly, the percentage should drop per the table (75% at 2, 60% at 3, …). This is a SOFT / informational check, not a fail-the-gate item: if you happen to reach exactly 9 members, the panel will show 31% (retail's own 0.3111111) while ACE's actual XP grant math currently uses .3 — a KNOWN, filed divergence between ACE and retail, not an acdream bug (register row AD-80). Do not report a 9-member mismatch between the panel's percentage and the XP you actually received.
24. [fix-round MUST-FIX 1, new step — a HARD check, not soft like step 23's ACE note] At exactly 6 and 8 fellows (even split, Share XP checked), the panel must show 44% and 34% respectively — NOT 45% or 35%. Retail TRUNCATES the percentage (_ftol2), it does not round; both stored float constants (0.44999998807907104 at 6, 0.3499999940395355 at 8) sit just BELOW the nice decimal, so retail's own truncation lands one point lower than naive rounding would produce. This is a genuine acdream-vs-retail bug if it shows 45%/35% instead of 44%/34% — unlike step 23's 9-member note, this is NOT an ACE-divergence exemption.
25. With Share XP UNCHECKED, the stats text should read "0%" for every member (retail's own literal pct = 0.0f branch, not a gap).

What to report (FA4-specific — in addition to the FA3 list above)

• The Create button staying enabled with an empty/whitespace-only name field, or staying disabled once real text is typed.
• Any roster row showing a blank name, a frozen level, or a vitals bar that never updates AT ALL while the panel is open and a second member is taking damage (contrast with step 8's EXPECTED freeze while the panel is CLOSED — that one is correct, not a bug).
• Fellow vitals staying frozen for the REST OF A NEW SESSION after a reconnect (step 9) — distinct from step 8's expected freeze, which clears within a second or two of reopening the tab.
• A membership change (join/leave) resetting your scroll position to the top of a long roster — the whole point of the FA3 carry-forward this slice closed (UiTemplateListBox.FlushPreservingScroll).
• Quit/Disband/Dismiss/AssignLeader/SetOpen not reaching the server (no visible effect on either client), or reaching it with the WRONG guid (e.g. Dismiss removing the wrong member).
• The leader hand-off (step 15) leaving the fellowship leaderless, or transferring leadership to the wrong member.
• Selecting a fellow in the WORLD (step 16) NOT enabling Dismiss/Leader or NOT highlighting their row.
• An invite dialog NOT appearing on the second client regardless of that client's own Ignore/Auto-Accept checkbox state (steps 19-21) — unless your local ACE build itself refuses/auto-joins the recruit server-side first, in which case no request ever reaches the second client and that is expected, not a bug.
• The two option checkboxes NOT staying mutually exclusive (both ending up checked at once).
• A 6- or 8-fellow percentage reading 45%/35% instead of 44%/34% (step 24 — a real acdream bug, not an ACE-divergence exemption).
• Any crash, hang, or exception in the log during create/recruit/ dismiss/quit/disband/leader/open actions, during a reconnect with the panel left open, or while the invite dialog is open.

Explicitly NOT in scope for this gate (FA4)

• Allegiance monarch/patron/vassal LIVE population, swear/break/kick wire sends, and their confirmation dialogs (FA5).
• Friends/Squelch add/remove/appear-offline/clear wire sends (D1 — out of campaign scope entirely, register row AD-79).
• The bot-vs-ACE two-session fellowship gate (FA6) — every step marked [TWO-CLIENT] above may be deferred there if a second account is not available for this connected gate.
• Retail's exact StringInfo-templated row/stats sentence and ACCharGenData::FormatName name canonicalization — acdream renders plain numeric composites and the raw typed name instead (register row AD-81); do not report "the text doesn't read like a full sentence" or "my typed name wasn't auto-capitalized" as bugs.