acdream/docs/plans/2026-08-11-fellowship-allegiance-campaign.md

Campaign FA — the retail social panel: Fellowship & Allegiance

For agentic workers: slices are executed by ONE Sonnet implementer at a time against this contract, then dual-lens Opus-reviewed, per §7/§8. The four research docs in §1 are the spec's data appendix — implementers MUST read the cited sections before coding; every table this plan references is committed there in full.

**Status: ACTIVE — planned 2026-08-11. FA1 CLOSED 2026-08-12; FA2 CLOSED 2026-08-12 (dual APPROVE-WITH-FIXES → fix round 4272ad0e/ded23067/ ed8b3ec9 → narrow re-review CLOSED cc1a319c, no reopen; CF-1 folded into the corrected FA5 slice row). FA3's dual-lens review landed APPROVE-WITH-FIXES on both lenses (mechanism: 2 MUST-FIX/9 SHOULD-FIX; blast: 1 MUST-FIX/6 SHOULD-FIX/1 NIT) → fix round CLOSED 2026-08-12 (9afa05b5/35c40a9b/ae772709/a5553904) with every finding applied, including two corrections to the connected-gate script itself (the refuted tab x-order, and a false-defect trigger that could not fire). FA3's narrow re-review CLOSED bf07b70e 2026-08-12, no reopen — FA3 is CODE-CLOSED; the user's connected gate is OWED (docs/research/2026-08-12-campaign-fa-test-script.md, corrected). The re-review's four non-blocking carry-forwards are folded into FA4's contract: the Flush() scroll-position reset under FA4's per-vitals-tick roster rebuilds; a production-resolver test for the new template cache; scrollbar-id literals promoted to the authored ScrollbarElementId; the bounded per-frame retry on a permanently unresolvable template. FA4 CODE-COMPLETE 2026-08-12 (357d2032 Runtime, 5bdd0528 App+tests) — implementer pass done, all four FA3 carry-forwards closed in this same slice; the dual-lens review (§7) and the user's connected gate (docs/research/2026-08-12-campaign-fa-test-script.md §FA4, several steps explicitly need a second account/character and are marked [TWO-CLIENT], deferrable to FA6's bot gate) are OWED.

Goal: retail's social panel — the four-tab gmPanelUI member at host slot 0x1000018F (panel id 12): Friends / Allegiance / Fellowship / Squelch — with the Fellowship and Allegiance pages fully live retail-faithful end-to-end (authored LayoutDescs, real wire, Runtime-owned state, live consumers), the Friends and Squelch pages bound read-only to the state Runtime already owns, and automated bot-vs-ACE gates for the two-session flows. Campaign directive: the 2026-08-11 /goal (Campaign FA).

Architecture: one panel mounted exactly like Campaign OP's Options panel (the OP3 recipe: LayoutImporter.ImportInfos(dats, 0x2100006E, 0x1000018F), Type-8 tab host + ActivateTabBehavior, per-page scoped controllers, RetailPanelCatalog id 12, F3/F4 keybinds). Fellowship and allegiance state live in TWO new sibling Runtime owners under GameRuntime per the Slice-J pattern. (different lifetimes: fellowship is session-scoped; allegiance survives reconnect behind a seed latch) [FA2 fix-round addendum, 2026-08-12: corrected — both owners are session-scoped and clear at every generation reset; see D2's addendum below for the full three-way evidence citation.] Wire parsers/builders live in AcDream.Core.Net beside the H.2 scaffolding they connect, repair, or replace. Both graphical and headless hosts are served by the single inbound wiring site.

---

1. Research base (committed; the spec's data appendix)

Doc	What it pins
docs/research/2026-08-11-fa-panel-structure.md (lane A + coordinator addendum §10)	The social-panel mount (slot 0x1000018F, id 12, four pages with RegisterElementClass identities), both element inventories, the row-template mechanism, the five confirmation dialogs, empty states, F3/F4 open path, the 16-slot host table, unknowns U3–U10
docs/research/2026-08-11-fa-fellowship-wire.md (lane B)	31-feature master table; per-message field order (golden-vector source); the byte-decoded IsFull >= 9 and the x87 XP-share table (1.0…0.28, 2.8× cap); four pinned ACE divergences (share .3, 900 s vs 600 s lock, dual shareLoot encodings, zeroed cp/lum); the two latent acdream builder defects; the 0x00A6-gates-vitals prerequisite; accept/decline = the shared confirmation triple (type 4); dead 0x01C9/0x01CA; 8 missing WeenieError strings
docs/research/2026-08-11-fa-allegiance-wire.md (lane C)	27 C→S + 5 S→C binary-verified messages; AllegianceProfile/AllegianceHierarchy layout with ELEVEN version gates; tree-assembly rules (orphan record ⇒ whole-message discard; sibling order REVERSES); ACE's deliberately-zeroed profile fields; the reuse verdict on ParseAllegianceInfoResponse and the DELETE verdict on Core/Allegiance/AllegianceTree.cs; the retail-faithful permanent dimming of the two allegiance notification bits
docs/research/2026-08-11-fa-acdream-seams.md (lane D)	The H.2 scaffolding inventory (11 event ids, 5 fellowship builders, swear/break, LogTextTypes, F3/F4 actions — all unreachable); the two-sibling-J-owner recommendation with the 8-edit template; the ONE inbound registration site; the six dimmed rows + their pinning tests; the panel-mount template; bot-gate requirements (second ACE account, role-discriminated policy, 7 commands, 7 assertions); 0x027C already has a handler to share

2. Design decisions (stated per the campaign directive; reactable at gates)

• D1 — one social panel, all four tabs ship. The DAT authors ONE four-page panel; mounting only two pages would be an invented divergence. Fellowship + Allegiance pages are this campaign's core (fully live). Friends + Squelch pages bind READ-ONLY to RuntimeCommunicationState's existing friends/squelch owners (J4.1) for display; their mutation actions (add/remove friend, squelch edit) are wired only if their wire is already served by ACE and trivially pinned in-slice — otherwise the action buttons are honest INERT with register rows (the OP3 precedent), completed post-campaign.
• D2 — two sibling Runtime owners. RuntimeFellowshipState (session-scoped, cleared at reset like external-container) and RuntimeAllegianceState (survives reconnect behind a HasServerSeed- style latch). [FA2 fix-round addendum, 2026-08-12: shipped the OPPOSITE finding for RuntimeAllegianceState — the "survives reconnect" half is proven wrong by three-way evidence (docs/research/2026-08-12-fa2-review-mechanism.md MUST-FIX 1): (1) the retail hook — ClientAllegianceSystem:: OnEndCharacterSession @0x00569FA0 tail-calls AllegianceProfile::Clear at exactly the per-character-session boundary this owner's reset would run at, mirroring the sibling ClientFellowshipSystem:: OnEndCharacterSession @0x005690A0 Fellowship already honored — FA2's fellowship half was byte-faithful, the allegiance half was the exact inverse of retail's behavior at the same hook; (2) the cited precedent's actual behavior — RuntimeCharacterOptionsState.ResetSession (src/AcDream.Runtime/Gameplay/RuntimeCharacterState.cs:1007-1017), the very HasServerSeed-style latch this decision named as its justification, CLEARS and re-latches on every reset; it does not persist. Its own doc comment names the exact hazard this row then walked into verbatim: "a stale seed surviving a session boundary could let a flush ship the PRIOR character's words over the new one's"; (3) the no-character-selector connect path — SessionPlayerComposition.cs:1127-1132 constructs LiveSessionConnectOptions with no character field, so LiveSessionController.StartCore falls through to CharacterList.TrySelectFirstAvailable: which character enters world at generation N+1 is resolved fresh from a server-supplied list, and nothing in RuntimeAllegianceState keyed on character identity. The process model does NOT preclude a cross-character reset on the graphical host, so a stale allegiance tree surviving reset could present as the WRONG character's monarch/rank/vassal list. Corrected semantics: RuntimeAllegianceState is now ALSO a RuntimeGenerationReset stage (RuntimeGenerationResetStage.Allegiance) with the identical clear-and-relatch shape as RuntimeFellowshipState and the RuntimeCharacterOptionsState precedent — the profile clears AND HasServerSeed drops to false at every generation reset, not just at terminal Dispose. The HasServerSeed latch's remaining job is exactly what its name says: distinguishing "no profile has arrived THIS generation" from "genuinely no allegiance" WITHIN a session — it is a within-session rendering gate, not a cross-reconnect persistence mechanism. The two owners remain separate classes (not merged into one) because fellowship and allegiance are independent retail systems with independent wire families, not because their lifetimes differ anymore.] Lane D's 8-edit template per owner; consumers poll via Snapshot.Revision — no IRuntimeEventObserver member is added (that would break all five bot policies + the trace recorder).
• D3 — the H.2 scaffolding is connected, repaired, or deleted — never trusted. Connect: the 11 GameEventType ids, AllegianceRequests swear/break, both LogTextTypes, F3/F4 actions. REPAIR: the fellowship builders (lane B: BuildFellowshipCreate invents an openness field ACE silently misreads as inverted shareXP; BuildFellowshipUpdate mislabels 0x00A6; the real openness action 0x0291 and leader-quit 0x0290 are missing) with their wrong-shape tests re-pinned to the verified field order. DELETE: Core/Allegiance/AllegianceTree.cs + its tests (passup formula ~1000× wrong and locked in by test; tree model contradicts the wire). REUSE: ClientCommandResponses. ParseAllegianceInfoResponse extended with the eleven version gates — no second profile parser.
• D4 — 0x00A6 (panel-open declaration) is wired to real panel visibility. ACE streams fellow vitals ONLY while the panel is declared open; without it the roster freezes at join. Sent on the fellowship page's show/hide through the page-visibility seam OP3 already exposes.
• D5 — parse defensively where ACE is internally inconsistent; display retail's own numbers. shareLoot is read as raw uint != 0 (ACE encodes it two incompatible ways). The XP-share percentage column uses retail's byte-decoded table (1.0/.75/.6/.55/.5/.45/.4/.35/.3111111/.28, default 0.0) — one register row records the knowing display divergence vs ACE's .3-at-nine-fellows server math.
• D6 — confirmations ride the existing dialog seam. Swear/accept- swear/break/kick/fellow-invite are plain Confirmation dialogs (0x0274/0x0275/0x0276, type 1 = allegiance, 4 = fellowship); acdream's RetailDialogFactory/GameplayConfirmationController already match the constants and its own comment names these types as awaiting FA. The missing third message of the triple is completed in FA1. The invite-receive path consumes IgnoreFellowshipRequests / FellowshipAutoAcceptRequests (auto-decline / auto-accept before the dialog), giving those two dimmed rows their real consumers.
• D7 — dimming resolves per lane-C/D verdicts. Un-dim (with the AD-78 conformance-test flow) exactly the rows that gain consumers: IgnoreFellowshipRequests, FellowshipAutoAcceptRequests (D6), and the fellowship share rows consumed by the create flow/panel display. IgnoreAllegianceRequests and DisplayAllegianceLogonNotifications stay dimmed PERMANENTLY and faithfully — retail's own client has no consumer for either (pure server-side filters); AD-78's register row gains an addendum saying so.
• D8 — bot-vs-ACE gates are first-class. A second ACE account/character (user-provided when FA6 arrives) + a role-discriminated headless policy let one bot recruit/swear at another, with the decisive assertion on the RECRUITED bot's own snapshot. All six FA option names are already tier-1 allow-listed.
• D9 — the 8 missing fellowship WeenieError strings are added in FA1 (two are on ACE's live send paths today; all resolve from the DAT string tables, never invented). [FA1 fix-round addendum, 2026-08-12: shipped the OPPOSITE finding — 5f9aa16f verified from primary source (case-label walk + else if chain sweep + whole-file sweep + decimal forms, docs/research/2026-08-12-fa1-review-mechanism.md §2(a)) that retail's Sept-2013 client has NO display text for any of the 8 ids. Inventing English for them would have been the exact failure mode the WeenieError table's no-default-case rule exists to prevent. acdream's existing silence for the two ACE actually sends (0x0417 FellowshipIgnoringRequests, 0x04DB FellowshipDeclined) is already retail-faithful; no strings were added, and none are owed. The conformance [Theory] at WeenieErrorMessagesTests.cs:390-393 (8 InlineData rows, each asserting Resolve() returns null) is the correct artifact in place of the string additions this decision originally called for. No register row is owed either — the register tracks acdream-vs-retail deviation, and this finding is that acdream already matches retail.]

3. Slice map

Dependencies: FA1 → FA2 → (FA3 → FA4/FA5) and FA2 → FA6; FA6 also needs FA4 (recruit) + FA5 (swear). FA7 closes. Default execution order: FA1, FA2, FA3, FA4, FA5, FA6, FA7.

Slice	Contract (summary)	Gate
FA1	Core.Net truth: repair fellowship builders + re-pin golden vectors; add 0x0290/0x0291/0x00A6/0x001F; the allegiance action set the panel needs (swear/break/kick/info at minimum; the rest of the 27 as builders only where ACE serves them); parsers for the 11 S→C events incl. the profile version gates (extending ParseAllegianceInfoResponse) and the tree discard/reversal rules; complete the confirmation triple; add the 8 WeenieError strings [FA1 fix-round addendum, 2026-08-12: shipped as CONFIRM-ABSENT instead — see D9's addendum. The 8 ids have no retail display text; acdream's silence is already faithful and a conformance test pins it.]; DELETE AllegianceTree	automated only
FA2	RuntimeFellowshipState + RuntimeAllegianceState (lane D's 8-edit template each); single-site inbound wiring serving BOTH hosts; typed commands/views; snapshot revisions; reset/reconnect semantics (session-scoped vs seed-latched [FA2 fix-round: both session-scoped — see D2's addendum]); bot event surface via polling	automated only
FA3	The social panel shell: mount slot 0x1000018F (catalog id 12), F3/F4 handlers, fixture dump of the slot (closes U3/U4/U6/U7/U10), tab activation, all four pages' empty states, Friends/Squelch read-only binding to J4.1 state	user (connected)
FA4	Fellowship page live: roster rows (adds UiTemplateListBox Flush/selection/row-instance-id — lane A sized this), the 0x00A6 show/hide declaration + vitals stream, create dialog (inline name field, shareXP), recruit/dismiss/quit/disband/leader + confirmations, share display per D5, option-row un-dims per D7	user (connected) + bot
FA5	Allegiance page live: profile parse on show (0x027B) [FA2 re-review CF-1 correction, 2026-08-12: the DATA subscription is 0x001F AllegianceUpdateRequest(on) — retail arms it at PostInit, RecvNotice_PlayerDescReceived, and the panel's visible branch, and 0x0020 AllegianceUpdate is the sole owner-seeder after the FA2 MF-2 fix; 0x027B's response is text-only chat. FA5 wires 0x001F(on) at those lifecycle points (off on hide per retail's visible branch) or the panel opens with chat text and no data]; monarch/patron/self blocks, flat vassal list with the reversal rule honored, swear/break/kick + confirmations, ACE zeroed-field presentation scoped honestly (register row). [FA3 fix-round addendum, 2026-08-12 (mechanism SF-7): FA3 shipped a COARSER empty-state gate than retail's own — both the monarch and patron blocks hide/show together on the single RuntimeAllegianceSnapshot.HasProfile flag. Retail's gmAllegianceUI::UpdateMonarchData @0x00491B40 gates PER-RELATIONSHIP: the monarch block additionally hides when the monarch IS the viewer, and the patron block hides on the analogous test. FA5 MUST widen SocialPanelController.Callbacks.AllegianceSnapshot (today Func<RuntimeAllegianceSnapshot>) to reach the per-relationship data IRuntimeAllegianceView.TryGetMonarch/TryGetPatron already expose (GameRuntimeGameplayViews.cs:200-204) and implement the real gate — a monarch character must NOT see an empty, visible monarch block, and a patron-of-the-monarch character must NOT see an empty, visible patron block. SocialAllegiancePageController.Tick also reassigns LinesProvider UNCONDITIONALLY every frame today — FA5's real name population must change this method in the same commit or its content is overwritten the next frame.]	user (connected) + bot
FA6	Bot-vs-ACE automated gates: second-account config (USER PREREQUISITE), role-discriminated policy, the 7 Runtime commands + 7 named assertions (decisive: the recruited/sworn bot's own snapshot flips), reconnect-idempotence	automated + bot-vs-ACE run
FA7	Closeout: register reconciliation, ISSUES sweep, CLAUDE.md Current-state paragraph, memory digest, the connected-gate test script (the campaign's stop condition)	user's final connected matrix

4. What is explicitly OUT of scope

• Friends/Squelch mutation wire beyond D1's trivially-pinnable bar (post-campaign completion; register rows).
• Allegiance officer/MOTD/banlist management UI — ACE zeroes or ignores most of it (lane C §ACE-caveats); builders may exist from FA1 but no panel surface beyond what the authored layout carries.
• XP passup FORMULAS client-side — _cp_tithed arrives pre-computed; the deleted AllegianceTree transcription is not replaced.
• The 0x01C9/0x01CA dead opcodes (COMDAT-folded no-ops in retail).

5. Verification discipline

Per commit: dotnet build -c Release + FULL Release suite green (baseline at plan time: 13,103 / 4 skips / 0 failures at 28bef4e0+the gate-4 fixes). Golden byte vectors for every wire builder against the lane-B/C field-order sections. Conformance pins for every panel inventory and the tab table. The live-DAT probe harness (ACDREAM_PROBE_LIVE_MOUNT=1) extended per slice — fixture-green alone is NOT acceptance for anything mounted (the #372/#375/#378 lesson). Register rows in the same commit as the deviation. No user-visible invented English ever.

6. Campaign OP lessons imported as binding rules

From claude-memory/project_settings_options_digest.md's DO-NOT-RETRY table and the gate rounds: pass the string resolver to EVERY LayoutImporter.Build; same-layout template-list prototypes are skipped by the importer (verify for this layout's templates); activate the Type-8 host or pages stack; seed lazily-created fill-anchored children with their parent extent; scoped FindDescendant for every id that repeats across pages (lane A: 0x10000492 twice INSIDE the allegiance page); popups get pointer priority via the UiRoot popup registration; straddling rows clip (never whole-cull); BN literal-0 operands are byte-verified before use.

7. Review protocol

Dual-lens Opus review per slice (mechanism-faithfulness × regression/blast-radius), fixes applied by the implementer; REJECT → focused re-review; TWO failures → Fable fixes directly. Findings persisted to a committed doc BEFORE any fixer/re-reviewer dispatch.

8. Process rules (binding, inherited from Campaign OP)

Max 3–4 agents in parallel INCLUDING children; every agent prompt carries an explicit no-subagent clause; ONE builder/tester on the tree at a time (read-only research may overlap); agents never launch the graphical client (headless bot-vs-ACE runs are allowed); the user runs connected gates; ledger placeholders anchored per-row; decomp claims byte-verified against the PDB-paired binary; stalled agents resumed via SendMessage before any redo; agent claims spot-verified at the seams before anything builds on them.

9. Ledger

Slice	Status	Commit(s)	Review	Gate
FA1	CLOSED 2026-08-12 — narrow re-review verdict CLOSED, no reopen (96df892d, §7 of the mechanism findings doc: all 7 mechanism dispositions re-derived in the diffs, all 6 blast dispositions spot-verified, suite claim corroborated on post-fix binaries); re-review carry-forward CF-1 (two further stale AllegianceTree citations in the seam map's FA2 guidance, :128/:214) closed by coordinator addenda in the same commit as this ledger update — FA2 was contracted not to start before that	7be86f47 (builders), 6bedbc47 (parsers), 5f9aa16f (WeenieError), 4281750b (delete AllegianceTree); fix-round: ed308087 (mechanism+blast MUST/SHOULD-FIX code+tests), this commit (register/plan/seams doc corrections)	mechanism docs/research/2026-08-12-fa1-review-mechanism.md (2 MUST-FIX, 5 SHOULD-FIX, all applied); blast docs/research/2026-08-12-fa1-review-blast.md (4 MUST-FIX, 5 SHOULD-FIX, all applied). Live-surface note (blast SF-1): FA1 changed the observable output of the ALREADY-LIVE @allegiance info command in two retail-faithful ways — vassal print order reversed (now pinned by a 3-vassal test through FormatAllegianceInfoLines) and a malformed tree now prints nothing instead of a partial roster (now pinned at the GameEventWiring layer) — not a "purely unwired" slice.	automated: Release build + full suite green throughout. Reconciled totals (blast MF-4): the ledger's own prior figure (13,149/4/0) is CONFIRMED correct by direct measurement at the pre-fix-round tip bc693728 (13,153 total = 4+916+1559+15+130+119+4856+877+4677 across all 9 test projects); the campaign-start baseline in §5 is 13,103/4/0, and the diff-verified FA1 delta is +58 added / −9 deleted (deleted AllegianceTreeTests.cs) = net +49, i.e. 13,103+49=13,152 — one test of drift against the directly-measured 13,153/13,149 baseline, attributed to the §5 baseline being captured at a different point in git history than the FA1 diff's actual parent, not a further miscount. This fix round adds a further +9 tests (2 golden vectors for the new 0x001F builder, 1 D5 <<1 pin at the 0x02C0 site, 4 MF-1/SF-1 boundary tests, 2 blast SF-1 live-surface pins) — final: 13,158 passed / 4 skipped / 0 failed (13,162 total), directly measured.
FA2	FIX-ROUND CLOSED 2026-08-12 — both reviews' MUST-FIX/SHOULD-FIX findings applied; automated gate only, per contract	RuntimeFellowshipState/RuntimeAllegianceState (2 new sibling J-owners, src/AcDream.Runtime/Gameplay/), the full 8-edit template applied twice (GameRuntime.cs, RuntimeGenerationReset.cs, RuntimeGameplayOwnership.cs/RuntimeSimulationOwnership.cs, GameRuntimeGameplayViews.cs, GameRuntimeCommands.cs, GameRuntimeEvents.cs, GameRuntimeViews.cs), 12 new WorldSession.Send* wrappers, 15 new GameEventWiring.WireAll delegate holes [FA2 fix-round addendum, 2026-08-12 (docs/research/2026-08-12-fa2-review-blast.md SHOULD-FIX 3): both counts were wrong. WorldSession.cs:2318-2404 adds 11 new Send* wrappers (7 fellowship + 4 allegiance) — SendAllegianceInfoRequest pre-dates FA2; the 12 figure belongs to a different count, cced83b4's *RuntimeCmd records / LiveSessionCommandBindings send delegates. GameEventWiring.cs:107-120 adds 10 delegate holes (9 new + the 0x027C fold), not 15 — matching the "11 S→C events" the seam doc's §2.3 table names, of which 2 (0x01C9/0x01CA) are correctly left unregistered (dead COMDAT-fold no-ops) and 1 (0x027C) was already registered pre-FA2.] registered at the single site (LiveSessionEventRouter.cs), both LiveSocialSessionBindings construction sites updated (LiveSessionRuntimeFactory.cs, HeadlessSessionHost.cs), IRuntimeFellowshipCommands/IRuntimeAllegianceCommands implemented on both host command adapters (DirectGameRuntimeCommandAdapter, CurrentGameRuntimeCommandAdapter + its LiveSessionCommandRouter/LiveSessionCommandBindings App-bus plumbing), divergence register rows TS-81 (filed) + TS-80 (narrowed); fix-round: 4272ad0e (mechanism MUST-FIX 1/2 + blast MUST-FIX 1/2 + blast SF-1 + mechanism SF-2 — allegiance reset semantics, 0x027C stops seeding, teardown-ledger off-by-one, conditional delegate holes, disposed-checks-inside-lock), ded23067 (mechanism SF-3/4/5/6 + blast SF-4/5/7 — RecalculateEvenXPSplitting, locked/departed admission gate, AllegianceProfileLookups reuse, non-null checkpoint defaults, router self/other-quit test, ResetSession disposed-guard parity, GetVassals allocation doc), this commit (register/plan/seams doc corrections)	mechanism docs/research/2026-08-12-fa2-review-mechanism.md (2 MUST-FIX, 6 SHOULD-FIX, all applied); blast docs/research/2026-08-12-fa2-review-blast.md (2 MUST-FIX, 7 SHOULD-FIX, all applied). Allegiance register-row re-evaluation (blast SF-6): the design blast SF-6 asked to be either dropped or given a register row is now fully retired by MF-1's fix — RuntimeAllegianceState clears at every generation reset exactly like RuntimeFellowshipState and exactly like retail's OnEndCharacterSession hook, so there is no remaining acdream-vs-retail deviation for allegiance persistence to name a row for. No register row added; conclusion recorded here per the fix-round contract.	automated: Release build + full suite green throughout. Pre-fix-round baseline 13,201/4/0 (13,205 total, measured at 12053e61 by the blast review) → fix-round 13,215/4/0 (13,219 total), +14 tests, arithmetic exact: RuntimeAllegianceStateTests.cs net +2 (−1 deleted ApplyInfoResponseSelf_..., +3 new ResetSession_*), RuntimeFellowshipStateTests.cs +10 (1 ResetSession_AfterDispose_... + 3 [Theory] cases for RecalculateEvenXPSplitting + 1 ShareXp-off case + 1 full-update-never-recomputes case + 4 locked/departed admission-gate cases), GameRuntimeTests.cs +1 (CompletedTeardownStagesAccumulatesExactlyOneFlagPerStage), Session/LiveSessionEventRouterTests.cs +1 (FellowshipQuit_RoutesSelfGuidToClearAndOtherGuidToRemove); RuntimeGenerationResetTests.cs and GameEventWiringTests.cs each renamed one test in place (net 0); GameRuntimeContractTests.cs gained two trailing constructor arguments at its sole positional RuntimeStateCheckpoint site (compile-fix only, no new test).
FA3	FIX-ROUND CLOSED 2026-08-12 — both reviews' MUST-FIX/SHOULD-FIX/NIT findings applied; still owes the user's connected gate (script: docs/research/2026-08-12-campaign-fa-test-script.md, itself corrected by this fix round — see MF-1/MF-2 below).	0a9ca2f1 (SocialPanelController + 4 per-page controllers + SocialPanelRowText, UiTemplateListBox.Flush, RetailPanelCatalog.SocialPanel/WindowNames.SocialPanel, RetailUiRuntime Mount/Tick/F3/F4 wiring, InteractionRetainedUiComposition's SocialRuntimeBindings, register row AD-79); 74c3d85d (fixture generator entry + committed social_panel_2100006E_1000018F.json, SocialPanelLiveMountProbeTests, SocialPanelControllerTests, RetailPanelCatalogTests additions, FixtureLoader additions); b6a25110/d7e1cffd (gate script + ledger + research addendum). Fix-round: 9afa05b5 (blast MF-1 scrollbar wiring + blast SF-2/SF-3 rebuild discipline/revision-latch ordering + mechanism SF-1 F3/F4 relabel + mechanism SF-8 disposed guard, code+tests), 35c40a9b (mechanism SF-2/blast SF-4 allegiance per-frame allocation hoist + mechanism SF-7 coarser-gate FA5 acceptance line), ae772709 (mechanism SF-4 fellowship checkbox count + mechanism SF-9 row-text doc + blast SF-5 Flush doc + mechanism SF-3 probe assertions), a5553904 (mechanism MF-1/MF-2 gate-script corrections + mechanism SF-4 gate-script hedge fix + blast N-8 two new gate steps + blast SF-6 #383 timing correction + blast SF-7 bold-marker fix + mechanism SF-1 research-doc U11), this commit (ledger update).	mechanism docs/research/2026-08-12-fa3-review-mechanism.md (2 MUST-FIX, 9 SHOULD-FIX, all applied); blast docs/research/2026-08-12-fa3-review-blast.md (1 MUST-FIX, 6 SHOULD-FIX, 1 NIT, all applied). Live-DAT finding (corrects the coordinator addendum, §10): the real authored 0x2E tab table pairs button 0x1000028C ("Allegiance" caption) with page 0x10000291 as the DEFAULT entry — NOT Friends, which the addendum's x-order guess implied; each page's own P0x57 independently corroborates (Allegiance page P0x57=0x1000000E == ToggleAllegiancePanel/F3, Fellowship page P0x57=0x1000000F == ToggleFellowshipPanel/F4). See SocialPanelController's class doc for the full corrected table. Unrelated fixture drift caught and reverted: the ACDREAM_REGENERATE_UI_FIXTURES=1 run used to produce the new fixture also silently regenerated keyboard_config_21000009.json and options_2100002B.json with large diffs against this machine's currently-installed DAT (pre-existing environment drift, not FA3-caused) — both were git checkout'd back to HEAD before committing; only the new fixture is included; the fix round's blast SF-6 correction narrows this drift to exactly those two OP-era fixtures (git timestamps put the drift window at ~18-21h, same day, not "days ago" as originally filed) and adds the mechanism reviewer's independent no-drift confirmation for the new social-panel fixture itself. Friends/Squelch action buttons are honest INERT per D1 (register row AD-79, one row covering both pages' seven controls, not one per button — now cited BY NAME in both page controllers' own doc comments, mechanism SF-6). The fix round's two connected-gate corrections (mechanism MF-1/MF-2) matter most for the still-owed user gate: the script previously carried a REFUTED tab x-order into step 1/9/10 (priming the user to report the correct Allegiance-left-most layout as wrong) and sent the user to a @allegiance info-reveals-the-panel trigger that cannot fire post-FA2 (told to report it as a bug when it correctly did nothing) — both are corrected to state the true FA3 expectation.	automated: Release build green throughout; full solution suite green at every commit. Pre-fix-round baseline 13,233/4/0 (13,237 total) → fix-round 13,238/4/0 (13,242 total), +5 tests, arithmetic exact: SocialPanelControllerTests.cs +5 (Friends_ScrollbarModel_IsWiredToListBoxScroll, Squelch_ScrollbarModel_IsWiredToListBoxScroll, Friends_LongRoster_IsReachableViaScrollbar, Squelch_LongRoster_IsReachableViaScrollbar, Friends_RevisionBumpWhileHidden_DoesNotRebuild_ButRebuildsOnShow); SocialPanelLiveMountProbeTests.cs gained two new assertions inside its existing single env-gated [Fact] (net 0 new test count — trivially passes without ACDREAM_PROBE_LIVE_MOUNT=1, same as before); two existing SocialPanelControllerTests.cs tests were extended in place (FriendsAndSquelchActionButtons_AreClickable_ButHaveNoHandler now also covers 0x1000052C; Friends_ReactsToRevisionChange_OnTick now calls OnShown() to match the new visibility gate) — net 0 new tests from those two. Directly measured per-project: Cli 4, UI.Abstractions 916, Runtime 1607, Bake 15, Content 130, Headless 119, App 4876/3 skip, Core.Net 895, Core 4676/1 skip — sum 13,238 passed / 4 skipped / 0 failed.
FA4	CODE-COMPLETE 2026-08-12 — implementer pass done; dual-lens review and the user's connected gate (several steps [TWO-CLIENT], deferrable to FA6) are owed	357d2032 (Runtime: IRuntimeFellowshipView.GetMembers, SelectionChangeSource.Social, +4 RuntimeFellowshipStateTests); 5bdd0528 (App: SocialFellowshipPageController roster/D4/create/actions/checkboxes rewrite, RowTemplateResolver extraction, UiTemplateListBox.FlushPreservingScroll, RetailUiRuntime D6 intercept + MountSocialPanel rewiring, Friends/Squelch scrollbar carry-forward 3, CharacterOptionsPageController D7 un-dim, extended SocialPanelLiveMountProbeTests, +30 tests); this commit (register rows AD-80/AD-81 + AD-78 addendum, gate script §FA4, ledger)	owed	automated: Release build green throughout; full solution suite green at every commit. Baseline 13,238/4/0 (13,242 total) → FA4 13,272/4/0 (13,276 total), +34 tests, arithmetic exact: RuntimeFellowshipStateTests.cs +4 (GetMembers_*); RowTemplateResolverTests.cs +3; UiTemplateListBoxFlushPreservingScrollTests.cs +4; SocialFellowshipPageControllerTests.cs +23 (new file — roster build/diff/rebuild, D5 formatting, create-flow gating, member-action wiring, button-enable rules, checkbox wiring, D4 idempotency). CharacterOptionsPageControllerTests.cs/SocialPanelControllerTests.cs/SocialPanelLiveMountProbeTests.cs extended in place (net 0 new tests from those three — one existing assertion's expected counts changed, one probe test gained assertions inside its existing single env-gated [Fact]). Live-DAT verification (ACDREAM_PROBE_LIVE_MOUNT=1, real installed DATs, not a fixture): the fellowship name-entry field builds as UiField (Editable=1 confirmed authored), all 11 buttons/checkboxes resolve as UiButton, the ListBox's sole template pair (0x21000030/0x10000281) resolves through the production RowTemplateResolver with all 5 checked row fields at the right widget types, every checkbox label/tooltip resolves to real retail English (ID_PlayerOption_* in 0x23000003), the Open/Close captions resolve to "Open"/"Close" (ID_Fellowship_* in 0x23000001), and a full production-path SocialFellowshipPageController.Bind() against the live layout emits zero "not found" console warnings. Structural finding (not a bug, a design confirmation): the live dump shows the name field, Create button, and all four checkboxes are children of 0x1000026B (the NOT-in-fellowship frame) — retail's Create-flow controls are visible ONLY while you have no fellowship, never simultaneously with the roster; the existing empty/full frame-visibility swap already produces this for free (child visibility cascades from an invisible ancestor — UiElement.cs:486/540/573/586), so no extra gating code was needed. Contradictions/deferrals: (1) the retail StringInfo variable-substitution engine (StringInfo::InqString → StringTableMetaLanguage::UnescapeString) is unresolved in this campaign's decomp scope — row/stats/vitals text renders as numeric composites, not retail's exact sentence (AD-81); (2) ACCharGenData::FormatName is unported — the Create flow sends the raw typed name, not retail's canonicalized form (also AD-81); (3) the D5 percentage table's proportional (non-even-split) branch needs a per-level XP-to-next-level table acdream does not have — that branch omits the percentage rather than computing one (documented in FormatStatsText's own doc, not a separate register row); (4) the Recruit button's enable rule does not gate on "target is a player" (retail does) — acdream's UI layer has no cheap classification for this, and the server refuses a non-player target the same way retail's own click-handler silently no-ops, so this is a superset-of-retail enable rule, not a wire-behavior gap (inline comment, not a register row).
FA5	—
FA6	—
FA7	—