erik/acdream
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 2

docs(fa4): fix-round register rows AD-82/AD-83, AD-78 count correction, gate-script SF-7/MUST-FIX-1/3 corrections

Browse source 
Register (docs/architecture/retail-divergence-register.md):
- AD-78: the Character-tab dimmed count had drifted stale through two
  campaigns (still read "35" after FA4 shipped 31; now 34 after the fix
  round's three reversions). Addendum explains the full D6/SF-8 chain.
  Blast review's own SHOULD-FIX 1.
- AD-82 (new): the invented leader-tint/selection-tint colors, the
  name-text-only row click target, and the page-local (not generic
  UiTemplateListBox) world->panel selection sync -- MUST-FIX 4's
  disposition plus two items MUST-FIX 5 named as owed rows.
- AD-83 (new): the Recruit button's missing "target is a player" gate,
  previously an inline comment, not a register row -- MUST-FIX 5's third
  item. Section header bumped 61 -> 63 active rows.

Gate script (docs/research/2026-08-12-campaign-fa-test-script.md):
- SF-7: fixed step 3's self-contradiction ("only Quit" then "Disband and
  Open should ALSO be enabled").
- MUST-FIX 3: new reconnect step after the existing close/reopen step.
- MUST-FIX 4: new world-selection step under the recruit/dismiss/quit
  section.
- MUST-FIX 1: new HARD-check step for the 6/8-fellow 44%/34% truncation
  (distinct from the existing SOFT 9-member ACE-divergence note).
- MUST-FIX 2 correction: the old invite steps tested whether acdream's
  CLIENT gates the dialog on the option bits -- a mechanism that never
  existed in retail and no longer exists in acdream. Rewritten to test
  the corrected behavior (the dialog always shows regardless of the
  target's own checkbox state) and to explain what ACE-side filtering
  would look like if the local server implements it, so a tester doesn't
  misattribute ACE's behavior to a client bug.
- Renumbered steps 9-22 to 9-25 to fit the two new steps; updated the
  "what to report" section's step cross-references and rewrote its
  invite/dimming bullets to match the corrected mechanism.

Plan (docs/plans/2026-08-11-fellowship-allegiance-campaign.md):
- D7 addendum: SF-8's further correction (FellowshipShareLoot reverts
  too; only FellowshipShareXP survives as genuinely live).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Erik 2026-08-12 07:34:09 +02:00
parent 55b17e15fd
commit 1d74327771
3 changed files with 135 additions and 51 deletions
Download patch file Download diff file Expand all files Collapse all files

6
docs/architecture/retail-divergence-register.md
View file

File diff suppressed because one or more lines are too long

15
docs/plans/2026-08-11-fellowship-allegiance-campaign.md
View file

@ -180,7 +180,20 @@ served by the single inbound wiring site.
allegiance bits, with no client consumer. FA4's un-dim of these two
REVERTS (dimmed count 31 → 33 of 50); only the fellowship SHARE rows the
create flow/panel genuinely reads stay un-dimmed. AD-78's addendum names
the corrected set.]**
the corrected set.]** **[FA4 FIX-ROUND further correction, 2026-08-12
(mechanism review SF-8): "the fellowship SHARE rows... genuinely reads"
above overstated it — only `FellowshipShareXP` is actually READ back by
acdream (the Create-flow click sends it as the `shareXP` wire bit).
`FellowshipShareLoot`'s claimed consumer, "a second live checkbox
surface on the fellowship page," is not a consumer at all: nothing in
acdream ever reads the stored value back (`FormatStatsText` uses
`snapshot.ShareXp` only; the `0x00A2` Create builder carries `shareXP`
alone), and the live-DAT dump confirms its checkbox is a child of the
NOT-in-fellowship frame — invisible whenever you actually have a
fellowship to loot-share within. `FellowshipShareLoot` REVERTS to
dimmed too (dimmed count 33 → 34 of 50; net ONE row un-dimmed from the
pre-FA4 baseline of 35, not four). AD-78's addendum names this final
corrected set.]**
- **D8 — bot-vs-ACE gates are first-class.** A second ACE
account/character + a role-discriminated headless policy let one bot
recruit/swear at another, with the decisive assertion on the RECRUITED

165
docs/research/2026-08-12-campaign-fa-test-script.md
View file

@ -276,11 +276,13 @@ section's own numbering.
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).
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
@ -317,32 +319,44 @@ behavior when closed — [TWO-CLIENT], the `0x00A6` gate made observable
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.
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
10. **[SOLO, self only]** With a solo (1-member) fellowship you lead,
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.
11. **[SOLO, self only]** Create another fellowship, then click
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.
12. **[TWO-CLIENT]** With two members, select the OTHER member's roster
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.
13. **[TWO-CLIENT]** With two members, select the other member's row
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) — 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
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
@ -350,45 +364,80 @@ behavior when closed — [TWO-CLIENT], the `0x00A6` gate made observable
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]
15. **With a fellowship active, note the Open/Close button's caption.**
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"** (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** —
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 + both option-bit behaviors — [TWO-CLIENT]
### The invite dialog — [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
**[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]
21. **With a solo (1-member) fellowship, Share XP checked, the stats
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
@ -399,7 +448,17 @@ behavior when closed — [TWO-CLIENT], the `0x00A6` gate made observable
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
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)
@ -410,21 +469,31 @@ behavior when closed — [TWO-CLIENT], the `0x00A6` gate made observable
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 14) leaving the fellowship leaderless, or
- The leader hand-off (step 15) 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).
- 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 or while the invite dialog is
open.
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)