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

docs(fa4): register rows AD-80/AD-81, AD-78 addendum, gate script section, ledger

Browse source 
Register: AD-80 files the D5 XP-share display divergence between
retail's byte-decoded table (acdream renders it verbatim) and the
currently-targeted ACE server's slightly different actual grant (.3 vs
.3111111 at 9 fellows, no 10-fellow row, wrong out-of-range default) --
an ACE-vs-retail gap, not an acdream-vs-retail one, filed because it is
directly user-visible through this panel. AD-81 files the two unported
retail text-composition primitives the fellowship page's mechanism
needs (StringInfo variable substitution, ACCharGenData::FormatName) and
what acdream renders instead (plain numeric composites, the raw typed
name). AD-78's derivation table gains its D7 addendum: 4 of the 35
store-only rows (IgnoreFellowshipRequests/FellowshipAutoAcceptRequests/
FellowshipShareXP/FellowshipShareLoot) moved to the Live bullet with
their new consumers named.

Gate script: new §FA4 section covering create (name + shareXP), the
open/close caption swap, button-enable rules, and the D5 display -- all
solo-testable -- plus roster/recruit/dismiss/leader-handoff/invite-
dialog steps marked [TWO-CLIENT] with an honest note that they defer to
FA6's bot-vs-ACE gate if a second account isn't available for this
connected gate. Corrects FA3's now-stale "these six buttons/four
checkboxes are INERT" claims in steps 11-12 to point at the new
section instead of leaving a wrong claim in place.

Ledger: FA4 row CODE-COMPLETE with both commit SHAs, the reconciled
13,238->13,272 (+34) test-count arithmetic, the live-DAT verification
summary (ACDREAM_PROBE_LIVE_MOUNT=1 against real installed DATs,
including the structural finding that retail's own frame-visibility
swap already gates the Create-flow controls away from the roster view
with no extra code needed), and the four scoped
deferrals/simplifications this slice made (the StringInfo/FormatName
gap, the proportional-share omission, the Recruit button's
superset-of-retail enable rule).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Erik 2026-08-12 04:41:53 +02:00
parent 5bdd0528f1
commit 38f08314c7
3 changed files with 221 additions and 19 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -1,9 +1,10 @@
# Campaign FA connected-gate test script
**Status: FA3 owes its connected gate.** 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.
**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
@ -11,6 +12,17 @@ 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
@ -84,17 +96,17 @@ absence here.
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.
**INERT:** the Create Fellowship button, the name field, and all
four checkboxes do nothing yet on click/edit (FA4 wires the create
flow and the checkboxes already have Options-tab live consumers —
this page's OWN copies are not yet cross-bound).
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), open the Fellowship tab instead expecting: a fellowship
name display, a member roster ListBox (empty rows — FA4 populates
them), and six buttons (Leader/Quit/Open/Recruit/Dismiss/Disband).
All six buttons are **INERT** for FA3.
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
@ -237,11 +249,194 @@ Inventory, and Vitae all restore their own last open/closed state too.
### Explicitly NOT in scope for this gate
- Fellowship roster population, vitals, the create-fellowship dialog,
recruit/dismiss/leader/open/disband wire sends, and the option-row
un-dims (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).
---
## 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.