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. Only the
   Quit button should be enabled (you're the leader, but with no other
   member selected, Leader/Dismiss stay disabled — see "button states"
   below) — Disband and Open should ALSO be enabled (you're the leader
   of a real fellowship now).
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. **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

10. **[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.
11. **[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.
12. **[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.
13. **[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) — 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.
14. **[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.

### The open-toggle caption swap — [SOLO]

15. **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"** (retail's button reads as the ACTION available, not
    the current state — lane A §4.1). Click again to flip back.
16. **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 + both option-bit behaviors — [TWO-CLIENT]

17. **Baseline (neither option bit set):** 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. **Accept it** — the second character joins, appears on
    the first client's roster.
18. **Repeat, but with "Ignore Fellowship Requests" CHECKED on the
    second client.** No dialog should appear at all — the invite is
    auto-declined silently (D6). Confirm the second character does NOT
    end up in the fellowship.
19. **Repeat, but 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). No dialog should appear — the second character
    joins IMMEDIATELY without any click.
20. **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]

21. **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.
22. **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).
- 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 14) leaving the fellowship leaderless, or
  transferring leadership to the wrong member.
- An invite dialog appearing when the ignore/auto-accept bit says it
  should not (or the reverse — no dialog when both bits are off).
- The two option checkboxes NOT staying mutually exclusive (both ending
  up checked at once).
- Any crash, hang, or exception in the log during create/recruit/
  dismiss/quit/disband/leader/open actions 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.