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

Campaign FA connected-gate test script

Status: FA3, FA4, and FA5 (below) all owe their connected gates. 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. FA6's bot-vs-ACE fellowship gate PASSED live 2026-08-12 (§FA6 below) and needs no connected re-gate; its allegiance half is DEFERRED (docs/ISSUES.md #384) with one [TWO-CLIENT] manual step in §FA6 that can help settle it.

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. (Re-review re-fix 2026-08-12: the re-declaration fires from the post-world EnteredWorld seam via SocialPanelController.RedeclareAfterWorldEntry, NOT the pre-world ResetSessionDeclaration, which only clears the latch — declaring before world entry was silently dropped by the world-gated command, the original defect.)
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.

---

FA5 — the Allegiance page fully live

Prerequisite: open the Allegiance tab (F3, or click it — it is the authored DEFAULT tab, so simply pressing F3 from a cold start lands here). All step numbers below restart at 1 for this section's own numbering.

Honest limitation up front, same shape as FA4's: swearing allegiance genuinely needs a SECOND character (you cannot swear to yourself, and retail requires the target to already be online and selected in the world). If a second ACE account/character is not available, 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.

The data subscription (CF-1) — profile populates on SHOW, not on

@allegiance info — [SOLO]

[FA2 re-review CF-1 correction, carried into this slice's own contract: the panel's data comes from 0x001F AllegianceUpdateRequest → 0x0020 AllegianceUpdate, NOT from the 0x027B/0x027C @allegiance info chat-command pair, which is text-only and does not feed the panel (FA2 MF-2's fix). Do not use @allegiance info as a trigger for anything in this section.]

1. With NO allegiance (a fresh character), open the Allegiance tab. The self line (your name/rank/follower count) renders at the top; both the monarch and patron blocks are HIDDEN (no allegiance means neither relationship exists) — the empty state FA3 already gated, now reachable live.
2. If you already have an allegiance (monarch and/or patron), the blocks should populate WITHIN A SECOND OR TWO of opening the tab — this is the 0x001F(1) → 0x0020 round trip. If the blocks stay empty indefinitely after opening the tab, that is the CF-1 subscribe failing to reach the server — a real bug, not a display gap.
3. Close the panel (or switch to Fellowship), then reopen the Allegiance tab. The data should still be there (or repopulate quickly) — closing/reopening exercises the visible-branch toggle (0x001F(0) on hide, 0x001F(1) on show) without losing the profile.
4. [reconnect, the FA4 MF-3-REOPEN analogue] Force a disconnect/ reconnect while ANY allegiance data was previously visible. Once the client re-enters the world on the new session, open (or confirm already-open) the Allegiance tab. EXPECTED: the profile repopulates on the new session within a second or two — this is RedeclareAfterWorldEntry's UNCONDITIONAL post-world 0x001F(1) resend, which fires regardless of whether the panel happens to be open at that exact moment (retail's own RecvNotice_PlayerDescReceived arm does not check panel visibility either — see the class doc's CF-1 section). BUG if the profile stays empty/stale for the rest of the new session — that would mean the exact bug class MF-3-REOPEN caught for Fellowship's 0x00A6 recurred here for 0x001F.

Monarch / patron / self blocks — [SOLO if you already have an

allegiance, otherwise needs a TWO-CLIENT swear first]

5. Your own line (top of the page) always shows your allegiance's name, your follower count, and your rank as plain numbers — retail's exact sentence wording is NOT reproduced (the unported StringInfo substitution engine, register row AD-85, same class as FA4's AD-81); do not report "it just shows a number, not a sentence" as a bug.
6. If you are a VASSAL (you have a patron who is not the monarch), the patron block shows their name and a follower-adjacent "experience passed up" number. If your patron IS the monarch (single-tier allegiance), the patron block should be HIDDEN and the monarch block should show an ADDITIONAL sub-line (the "experience passed up" number) that does not appear for a multi-tier allegiance — this is retail's PatronSlashMonarchLabel swap (fix-round SF-7, the coarser FA3 gate's own owed correction).
7. If you ARE the monarch of your allegiance, the monarch block should be HIDDEN (retail hides it when the monarch IS the viewer, not just when there is no monarch at all) — confirm this specifically if you can arrange to be a monarch; it is easy to miss since "no monarch block" looks identical whether you have no allegiance at all or you're sitting at the top of one.
8. A logged-out monarch or patron's block should render visually dimmed (their name still shows, but the block itself looks "greyed"/disabled) — retail's SetState(1)/SetState(0xD) per-block online/offline toggle. This needs a second client to log out while you're watching, so mark it [TWO-CLIENT] if you can't arrange it solo.

Vassal list — [TWO-CLIENT for a populated list; SOLO to confirm the

empty case]

9. With no vassals, the vassal list box is simply empty (no placeholder text, matching retail — there is no "you have no vassals" frame the way Fellowship has an empty-state frame swap).
10. With one or more vassals (needs a second character sworn to you — see the swear steps below), each row shows the vassal's name and an "experience passed up" number (their OWN tithed amount, not yours — distinct from the monarch/patron block's number, which is YOUR OWN tithed amount).
11. An OFFLINE vassal's row should visually distinguish itself (acdream tints the name grey rather than porting retail's dedicated offline-marker element visually — confirm SOME visible difference between an online and offline vassal row).
12. With several vassals, scroll the list if it overflows the visible area and confirm every row remains reachable via the scrollbar (same UiTemplateListBox mechanism FA3/FA4 already gated).
13. Sibling order — a SOFT/informational check, not a fail-the-gate item. If you can arrange three or more vassals sworn to the same patron in a KNOWN order, the list should render them in REVERSE swear order (the last one to swear appears FIRST) — this is retail's own tree-assembly rule (lane C §4.4 point 3), not a display bug. Hard to verify without careful setup; report what you observe but do not treat a mismatch as an automatic fail without double-checking the actual swear order first.

Swear — [TWO-CLIENT]

14. On the SECOND client (the would-be vassal, with NO current patron), select the FIRST client's character in the world (click their 3D model) and click Swear on the Allegiance page. EXPECTED: a confirmation dialog appears on the SECOND client asking to confirm swearing allegiance — the message is whatever retail's template resolves to VERBATIM, or the target's bare name if the template did not resolve (register row AD-85 — do not report "the dialog doesn't read like a full sentence" as a bug).
15. Accept the dialog on the second client. EXPECTED: the FIRST client (the new patron) receives ITS OWN confirmation dialog asking to accept the new vassal — this is the SERVER-DRIVEN ConfirmationType 1 round trip (GameplayConfirmationController, generic, no allegiance-specific code), showing ACE's own message (typically just the vassal's bare name, lane C §6.4 — again, not a full sentence; not a bug).
16. Accept the dialog on the first client too. Both clients' Allegiance pages should update: the second character now shows a patron block naming the first character; the first character now shows the second character as a new row in their vassal list.
17. Swear button enable rule — with NO current patron and a player selected in the world who is not already in your allegiance, Swear should be ENABLED; with a patron already sworn, or nothing selected, or yourself selected, it should be DISABLED. [register row AD-84] acdream does not check "is the selection a player" the way retail does — selecting a non-player object (a monster, an item) may leave Swear lit when retail would grey it out; the server refuses the send either way, so this is a cosmetic gap, not a wire-behavior bug — do not fail the gate over it, but do note it if you observe it.
18. Reject the swear-target dialog (step 14) instead of accepting. No dialog reaches the first client; nothing changes on either side.
19. Reject the accept-swear dialog (step 15) instead of accepting. The second character does NOT become a vassal; both clients' allegiance state stays as it was before step 14.

Break and Kick — [TWO-CLIENT] (needs an existing swear relationship

from the steps above, or a pre-existing allegiance)

20. As the VASSAL, click Break. A confirmation dialog appears asking to break allegiance FROM your CURRENT patron (target latched at click time, matching retail — changing your world selection after clicking Break should NOT change who you break from, since Break's target is your patron, not a world selection at all). Accept it: your patron block clears/hides; the patron's vassal list loses your row.
21. As the PATRON, select a vassal row (click their name in the vassal list — NOT the world) and click Kick. A confirmation dialog appears asking to kick that SPECIFIC vassal. Accept it: they are removed from your vassal list; their own client's patron block clears/hides.
22. Kick button enable rule — with no vassal row selected, Kick should be DISABLED; select any vassal row and it should ENABLE.
23. Break button enable rule — with no patron, Break should be DISABLED; with any patron, it should be ENABLED.
24. Reject either dialog (Break or Kick) instead of accepting — no change on either client, no crash or stuck dialog state.

The IgnoreAllegianceRequests checkbox — [SOLO]

25. The checkbox on this page and the SAME-named row on the Options → Character tab are the SAME value — toggling one should reflect on the other (open both surfaces side by side, or toggle-then-reopen to confirm). This bit is a pure server-side filter with no client-side consumer in retail either (lane C §1.6) — checking it does not change any OTHER client-visible behavior; do not report "checking it doesn't seem to do anything" as a bug, that is correct.

ACE-zeroed fields — honest, not a bug

26. You will never see officer names, a message-of-the-day, a lock indicator, or an "allegiance age" anywhere on this page. Retail's OWN gmAllegianceUI has no widgets for any of these either (they are chat-verb-only in the 2013 client — @allegiance officer, @allegiance motd, etc., all out of this campaign's scope) — do not report their absence as a bug. Separately, even the CHAT-VERB versions of these features (if you try them) will show blank/default values against the currently-targeted ACE build, because ACE deliberately zeroes these fields on the wire regardless of the allegiance's real state (register row AD-86) — that is an ACE-vs-retail divergence, not an acdream bug either way.

What to report (FA5-specific — in addition to the FA3/FA4 lists above)

• The Allegiance tab NOT being the panel's default (step 1 of §FA3 already covers the tab itself; this section is about its DATA) — the profile never populating after opening the tab (step 2), or staying stale after a reconnect (step 4).
• The monarch block staying VISIBLE while you are the monarch yourself (step 7), or the patron block staying visible while your patron is the monarch (step 6) — both are the exact SF-7 per-relationship gate this slice fixed; a coarse "both blocks show whenever I have ANY profile" regression would be the FA3 bug resurfacing.
• The monarch/patron "experience passed up" sub-line failing to appear under the correct block per step 6's single-tier-vs-multi-tier distinction.
• A vassal row not appearing at all after a successful swear (step 16), or an online/offline vassal being visually indistinguishable (step 11).
• Swear/Break/Kick sending the WRONG target guid — e.g. Break targeting something other than your actual current patron, or Kick targeting a vassal other than the one you clicked.
• Either confirmation-dialog direction of Swear (steps 14/15) not appearing, or accepting one but not sending the matching wire command.
• The IgnoreAllegianceRequests checkbox NOT staying in sync between this page and the Options → Character tab (step 25).
• Any crash, hang, or exception in the log during swear/break/kick, during a reconnect with the Allegiance tab open, or while a confirmation dialog is open.

Explicitly NOT in scope for this gate (FA5)

• The bot-vs-ACE two-session swear 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 sentences for followers/rank/ experience-passed-up and the three confirmation dialogs — acdream renders plain numbers and, for dialogs, either retail's unsubstituted template text or the bare target name (register row AD-85); do not report "it just shows a number" or "the dialog doesn't read like a full sentence" as bugs.
• Officer/MOTD/lock/ban/hometown management — chat-verb-only in retail, out of this campaign's scope entirely (§4 of the plan), and unreliable against the currently-targeted ACE build regardless (register row AD-86).
• Swear's missing "target is a player" enable-rule check (register row AD-84) — a cosmetic superset-of-retail gap, not a wire-behavior bug.

---

FA6 — the bot-vs-ACE two-session gate

Unlike FA3-FA5, this is not a graphical-client gate: no window is launched. The coordinator runs acdream-headless run with a config declaring TWO sessions — testaccount/+Acdream as the fellowship LEADER/allegiance PATRON, testaccount2 as the fellowship RECRUIT/ allegiance VASSAL — both selecting policy id fellowship-allegiance-gate with role: "leader"/role: "recruit". Both sessions run in the SAME process, ticked sequentially on one dedicated update thread.

Automated fellowship gate — the shipped, passing part

Recipe:

{
  "version": 1,
  "sessions": [
    {
      "id": "fa6-bot-a-leader",
      "endpoint": { "host": "127.0.0.1", "port": 9000 },
      "account": "testaccount",
      "character": { "name": "+Acdream" },
      "policy": { "id": "fellowship-allegiance-gate", "role": "leader" },
      "credential": { "provider": "environment", "reference": "FA6_BOT_A_PASSWORD" }
    },
    {
      "id": "fa6-bot-b-recruit",
      "endpoint": { "host": "127.0.0.1", "port": 9000 },
      "account": "testaccount2",
      "character": { "index": 0 },
      "policy": { "id": "fellowship-allegiance-gate", "role": "recruit" },
      "credential": { "provider": "environment", "reference": "FA6_BOT_B_PASSWORD" },
      "characterOptions": { "FellowshipAutoAcceptRequests": true }
    }
  ]
}

The Recruit session's character selector deliberately does NOT hard-code a name — {"index": 0} picks the first available character on testaccount2, and the Leader bot discovers that character's real name live (FellowshipAllegianceGateCoordinator.RecruitCharacterName, set by the Recruit bot's own HeadlessSessionHost the instant CharacterList selection resolves it) rather than trusting a config-file guess. Run it: acdream-headless run --config fa6-gate.json with FA6_BOT_A_PASSWORD/ FA6_BOT_B_PASSWORD set in the environment. The process is self-terminating — every policy stage carries its own timeout, and the run ends (gracefully, with ACE-confirmed per-character logout) on its own once both bots reach Done or fault. Do not timeout/Ctrl+C the process mid-run: an external kill during an in-world session leaves ACE holding a stale session for ~3 minutes (CLAUDE.md's documented logout-before- reconnect discipline; one of this slice's OWN runs discovered this firsthand from wrapping a probe run in bash's timeout, not from the gate's own code path).

What the fellowship gate proves, per stage:

1. Proximity. The Leader sends retail's admin @teleallto (no target = "teleport everyone online to me") on a 5 s retry, then polls RuntimeFriendlyTargetQuery.FindPlayerByName for the Recruit bot's discovered name specifically — NOT the ambiguous "nearest any player" query, which a live run found picks up a stray third character on a shared ACE dev instance if one happens to be online nearby.
2. Create + recruit. Fellowship.Create then Fellowship.Recruit against the name-matched guid.
3. The decisive assertion. The Recruit bot's OWN RuntimeFellowshipState — a completely separate process's canonical Runtime owner, not the Leader's local echo — flips IsInFellowship=true, MemberCount=2, LeaderGuid=<Leader's guid>. This is the proof that 0x02BE/0x02C0 inbound reached a real second client, not just that the Leader's own send succeeded.
4. D4 panel-open + vitals. The Leader declares SetPanelOpen(true) (0x00A6) and asserts the Recruit's own fellowship member row already carries nonzero vitals (MaxHealth) — headless bots have no panel to freeze/unfreeze, so this proves the declaration sends and that vitals data is present, not the freeze-while-closed half of D4 (that remains a graphical-client-only observation, FA4's own owed connected gate).
5. Mid-flow reconnect. Both bots reconnect (commands.Session.Reconnect) after establishing, then assert the fellowship state re-seeds from scratch (a fresh generation clears RuntimeFellowshipState per FA2 D2) — proving reconnect-idempotence over the real wire, with a genuine second account watching.
6. Teardown. The Leader disbands (Fellowship.Quit(disband: true)); both bots assert their own IsInFellowship clears.

Result — PASSED, 2026-08-12 (five of six live runs; the sixth, run 2, hit a since-fixed wrong-target bug before the decisive stage was even reached):

[fa6-recruit] DECISIVE ASSERTION PASSED: own RuntimeFellowshipState
flipped IsInFellowship=true, MemberCount=2, LeaderGuid=0x5000000A —
recruit inbound path reached THIS process's own Runtime owner
[fa6-leader] panel-open declared; recruit vitals name='+Horan'
maxHealth=201

Two real defects surfaced and were fixed IN this slice, both now covered by conformance tests: headless hosts silently dropped every server-driven confirmation (HeadlessSessionHost.OnConfirmationRequest was null); and RuntimeFriendlyTargetQuery.FindClosestOtherPlayer's "nearest any player" query picked up a stray third character (+Je, 0x50000001) instead of the actual Recruit bot after @teleallto, fixed by the name-matched FindPlayerByName.

Allegiance bot gate — DEFERRED (docs/ISSUES.md #384)

Status: not shipped as an automated gate. The allegiance half of the SAME policy classes (Leader's WaitForVassal; Recruit's Swear/ WaitSwornSeed/Break/WaitBrokenSeed) is fully written and wired — proximity, the 0x001D swear send, a confirmation-relay seam on the Leader (the would-be patron, per docs/research/2026-08-11-fa-allegiance- wire.md §1.3's "Target (would-be patron)" steps 4-7), the decisive TotalVassals/TryGetPatron assertions, break, and reconnect-idempotence — but is gated OFF by default (AllegianceGateEnabled = false in both policy classes) because it has never actually completed over the wire. Six live runs against local ACE all showed the same symptom: ACE returns nothing to the swear — no 0x0274 confirmation, no 0x0020 tree update, no WeenieError — confirmed at 0.005 m separation between the two bots (ruling out retail's 2.0 m swear-distance gate). See docs/ISSUES.md #384 for the full evidence trail and register row AD-87 for the divergence this creates (the allegiance wire/state code is unit-tested and locally-echoed but not wire-verified end-to-end).

[TWO-CLIENT] Manual counterpart for the user's connected gate — this is the step that can settle #384 outside the headless harness:

25. With TWO graphical clients logged into different characters near each other (the existing FA5 [TWO-CLIENT] swear steps 14-16 already exercise this UI path), have character A select character B and click Swear. Report specifically: does B's client show the incoming "accept swear" confirmation dialog at all? If B accepts, does A's Allegiance page then show B in A's vassal list, and does B's page show A as patron? If the SAME silent non-response reproduces in the graphical client (no dialog ever appears on B's side, no error on A's), that points at an ACE-side rule or a genuine defect in acdream's 0x001D wire builder rather than anything specific to the headless harness — the two clients are real user accounts, not testaccount/ testaccount2, which also rules out any GM-flag-specific explanation. If it works normally in the graphical client, the symptom is scoped to testaccount/testaccount2 specifically (a GM flag, a rank/self- allegiance precondition, or state left over from this session's testing) — re-run the headless gate with a different account pair before reopening #384 as a real wire bug.

Explicitly NOT in scope for this gate

• A fully verified allegiance bot gate — deferred to #384; do not report its absence as a regression, and do not re-run the headless allegiance path repeatedly hoping for a different result without new information (six identical live results is enough evidence, not bad luck).
• Kick — no test exercises it (would need a THIRD account to have a vassal to kick that isn't also the tester).
• Kick/kick-confirmation UI — FA5's own [TWO-CLIENT] scope, unrelated to this bot gate.