acdream/docs/research/2026-08-12-fa2-review-mechanism.md

Campaign FA slice FA2 — mechanism-faithfulness review

Reviewer lens: mechanism faithfulness (retail behavior vs. shipped code). Target: 1c401048 (Core.Net), 369729f0 (Runtime), cced83b4 (App/Headless), 12053e61 (docs/ledger), against docs/plans/2026-08-11-fellowship-allegiance-campaign.md slice FA2 + D2/D4, lanes B/C/D (2026-08-11-fa-fellowship-wire.md, 2026-08-11-fa-allegiance-wire.md, 2026-08-11-fa-acdream-seams.md incl. its FA1 fix-round addenda), and the J4.x precedent closeouts. Date: 2026-08-12.

Verdict

APPROVE-WITH-FIXES — 2 MUST-FIX, 6 SHOULD-FIX.

Both MUST-FIX findings are on the allegiance owner and they compound: the owner is seeded from a message retail never seeds from (MF-2), and it is never cleared at the boundary retail clears it at (MF-1). Every fellowship mechanism in the slice re-derived clean against the decomp. Nothing in the wiring, command, view, teardown, or register work is wrong.

Neither MUST-FIX is user-visible today — no FA2 command or view has a production consumer yet (verified below). They are must-fix because FA3–FA5 build the panel directly on this owner, and MF-1 is already pinned by a passing test, which is the "wrong behavior locked in by test" shape FA1's own review called out when it deleted AllegianceTree.

---

1. MUST-FIX

MF-1 — Allegiance surviving a generation reset contradicts retail, contradicts its own cited precedent, and is pinned by a test

RuntimeAllegianceState participates in no reset stage (src/AcDream.Runtime/RuntimeGenerationReset.cs:39-41 says so explicitly; src/AcDream.Runtime/Gameplay/RuntimeAllegianceState.cs:18-27 documents the intent), and tests/AcDream.Runtime.Tests/RuntimeGenerationResetTests.cs (FellowshipClearsAtResetButAllegianceSurvivesReconnect) asserts the profile, the name and HasServerSeed all survive ResetGeneration.

(a) Retail clears it at exactly this boundary.

00569fa0  void __fastcall ClientAllegianceSystem::OnEndCharacterSession(...)
00569fa3      return AllegianceProfile::Clear(&this->m_allegianceProfile);

(docs/research/named-retail/acclient_2013_pseudo_c.txt:375000-375004, symbols.json 0x00569FA0.) AllegianceProfile::Clear @0x005B6A60 (:453700-453707) zeroes _total_members, _total_vassals and tail-calls AllegianceHierarchy::Clear — the whole tree.

The sibling hook is the control that proves the boundary is the right one:

005690a0  void __fastcall ClientFellowshipSystem::OnEndCharacterSession(...)
005690a8      if (m_pFellowship != 0) m_pFellowship->vtable->__vecDelDtor(1);
005690b0      this->m_pFellowship = nullptr;

(:373778-373790.) FA2's fellowship half is byte-faithful; the allegiance half is the exact inverse of what retail does at the same hook.

The hook is a per-character-session pair, and it maps 1:1 onto acdream's generation: UIQueueManager::OnBeginCharacterSession fires on PlayerDescription (0x13, @0x0055B173, :359247) and UIQueueManager::OnEndCharacterSession fires from gmGamePlayUI::~gmGamePlayUI (@0x004EA339, :238072), fanning out to every client system's vtable slot (UIQueueManager::OnEndCharacterSession @0x0055A6D0, :358492-358501).

Corroboration that the cached profile really is per-session state: gmAllegianceUI::RecvNotice_AllegianceLogin @0x00492220 (:158415-158426) gates every logon/logoff line on AllegianceProfile::GetData(&eax->m_allegianceProfile, guid, …) — the cached profile, i.e. the thing Clear empties.

(b) The cited precedent CLEARS and re-latches — the citation is inverted.

RuntimeAllegianceState.cs:24-27 and lane D §1.3 (2026-08-11-fa-acdream-seams.md:144-148) both justify persistence as "same class as RuntimeCharacterOptionsState's HasServerSeed latch". That precedent does the opposite:

// src/AcDream.Runtime/Gameplay/RuntimeCharacterState.cs:1007-1017
public void ResetSession()
{
    Volatile.Write(ref _options1, DefaultOptions1);
    Volatile.Write(ref _options2, DefaultOptions2);
    Interlocked.Increment(ref _revision);
    lock (_dirtyGate) { _isDirty = false; _hasServerSeed = false; }
}

and its own doc comment (:999-1006) names the hazard FA2 is now exposed to verbatim: "a stale seed surviving a session boundary could let a flush ship the PRIOR character's words over the new one's." It runs every generation via reset stage Character = 7 → RuntimeCharacterState.ResetSession → Try(Options.ResetSession, …) (RuntimeCharacterState.cs:442).

(c) The process model does NOT preclude a cross-character reset.

The graphical host constructs its connect options with no character selector:

// src/AcDream.App/Composition/SessionPlayerComposition.cs:1127-1132
new LiveSessionConnectOptions(
    d.Options.LiveMode, d.Options.LiveHost, d.Options.LivePort,
    d.Options.LiveUser ?? string.Empty, d.Options.LivePass ?? string.Empty)

LiveSessionConnectOptions.Character therefore defaults to null (src/AcDream.Runtime/Session/LiveSessionContracts.cs:16), so LiveSessionController.StartCore (:611-618) falls through TrySelectCharacter (:841-852) to CharacterList.TrySelectFirstAvailable, whose only filter is IsAvailableActiveIdentity(c) => c.Id != 0 && c.SecondsGreyedOut == 0 (src/AcDream.Core.Net/Messages/CharacterList.cs:111-112) — and ACE derives secondsGreyedOut from character.DeleteTime (references/ACE/.../GameMessageCharacterList.cs:28). Which character enters world at generation N+1 is resolved fresh from a server-supplied list, and nothing in RuntimeAllegianceState keys on character identity. The reset genuinely runs between the two: StopCore (LiveSessionController.cs:676-701) always drains the retired scope, whose teardown calls Host.ResetSessionState(Generation) (:231), which is the graphical host's _domain.Runtime.ResetGeneration(...) hop (src/AcDream.App/Net/LiveSessionRuntimeFactory.cs:193).

Headless is not exposed: HeadlessSessionHost requires exactly one selector field (MapCharacterSelector, :830-835; a fully-null selector makes selectorCount != 1 and TrySelectCharacter returns false), so each headless root is character-pinned for its whole life. The exposure is the graphical host only — but the graphical host is the one FA3–FA5 target.

(d) There is no re-seed that would mask it.

ACE pushes 0x0020 AllegianceUpdate on a tree change (AllegianceManager.cs:398, Allegiance.cs:361) or in reply to 0x001F (GameActionAllegianceUpdateRequest.cs:9-22). FA2 wires no 0x001F sender to any lifecycle event (verified in SF/clean §3.4). Retail's own re-seed is gmAllegianceUI::RecvNotice_PlayerDescReceived @0x00490D59 → Event_UpdateRequest(1) (lane C §1.2), which acdream does not have yet. So for a second character with no allegiance, character A's AllegianceName, monarch, vassal list, HasProfile and HasServerSeed stay readable indefinitely.

Recommended fix. Add RuntimeGenerationResetStage.Allegiance calling a new RuntimeAllegianceState.ResetSession() that clears the profile and _hasServerSeed (mirroring the options precedent exactly); invert the test; correct plan §2 D2 and lane D §1.3's inverted precedent citation. Anchor the missing PlayerDesc-triggered 0x001F(1) resubscribe to FA5 as a TS row so the clear does not silently mean "blank until the panel is opened". If the campaign still wants persistence after seeing this, it needs BOTH a divergence-register row (CLAUDE.md: same commit as the deviation) AND a character-identity key on the retained data — persistence with no identity guard is the failure mode, not the persistence itself.

MF-2 — 0x027C AllegianceInfoResponse must not seed the cached profile; retail's handler is print-only

RuntimeAllegianceState.ApplyInfoResponseSelf (RuntimeAllegianceState.cs:101-116) writes monarch, records, name, totals, _hasProfile and _hasServerSeed from 0x027C. Retail does not.

The dispatcher unpacks 0x027C into a stack-local profile and destroys it at return:

006a7470  CM_Allegiance::DispatchUI_AllegianceInfoResponseEvent(...)
006a74cd      void var_118;  CAllegianceProfile::CAllegianceProfile(&var_118);
006a74f1      AllegianceProfile::UnPack(&var_118, &arg2, …);
006a74ff      ClientAllegianceSystem::Handle_Allegiance__AllegianceInfoResponseEvent(
                  arg1->m_pAllegianceSystem, edi, &var_118);
006a750a      AllegianceHierarchy::~AllegianceHierarchy(&var_114);

(acclient_2013_pseudo_c.txt:686294-686313.) The handler (@0x0056A1D0, :375144-375210) reads only arg3 and calls ClientSystem::AddTextToScroll — it never touches this->m_allegianceProfile.

Contrast the only path that does seed:

0056a120  ClientAllegianceSystem::Handle_Allegiance__AllegianceUpdate(...)
0056a129      AllegianceProfile::operator=(&this->m_allegianceProfile.vtable, arg2);

(:375103-375109.) 0x0020 is the single inbound writer of the cached profile, which is why lane C describes 0x0020 as the subscribed push and 0x027C as a query response.

Second-order defect the divergence already carries. 0x027C has no rank field, so ApplyInfoResponseSelf deliberately retains the previous _rank (RuntimeAllegianceState.cs:97-99). On a client where the only allegiance message ever received is a self @allegiance info response, Snapshot.HasProfile == true with Snapshot.Rank == 0 — FA5's monarch/self block would render a ranked character as rank 0 (no title). That state is unreachable in retail precisely because retail never seeds from 0x027C.

Recommended fix. Drop ApplyInfoResponseSelf, its onAllegianceInfoResponseSelf delegate hole, and the self-gate, leaving the @allegiance info chat path exactly as it is today (the fold itself is correct — see §3.2). If it is kept deliberately, it needs a register row naming the rank hazard.

---

2. SHOULD-FIX

SF-1 — The nine new delegate holes are passed unconditionally, so nine event types silently leave the unhandled-count diagnostic. LiveSessionEventRouter.cs:238-264 passes non-null lambdas (update => social.Fellowship?.ApplyFullUpdate(update) etc.) regardless of whether social.Fellowship/Allegiance is supplied, so GameEventWiring's if (onX is not null) guards always pass and the handlers always register. GameEventDispatcher.Dispatch (:95-117) only increments _unhandledCounts when there is no registration, so GetUnhandledCount(FellowshipFullUpdate) and its eight siblings now read 0 for any caller that did not supply an owner (bare-ChatLog tests, future partial hosts) even though the parse result is discarded. Pass the delegates conditionally, or hoist the null check to the binding site.

SF-2 — Disposed check is outside the lock in both new owners (TOCTOU). Every mutator does ObjectDisposedException.ThrowIf(IsDisposed, this) and then takes _gate separately (RuntimeFellowshipState.cs:69-71, 94-96, 112-114, 133-135, 148-150, 207-208; RuntimeAllegianceState.cs:80-82, 104-106, 132-134, 139-141, 146-148). IsDisposed takes and releases the lock itself, so an inbound event racing Dispose can repopulate _members/_records after _disposed = true, permanently falsifying CaptureOwnership().IsConverged and failing the J-slice ownership ledger at teardown. The established precedent checks inside the lock (RuntimeCommunicationState.cs:377-379). Inbound events run on the decode thread and Dispose on the host thread, so this is a real window, currently masked by the router's accepting gate.

SF-3 — Retail's client-side RecalculateEvenXPSplitting is not modelled. Fellowship::UpdateFellow @0x005B9730 calls Fellowship::RecalculateEvenXPSplitting(this) at @0x005B9785 on every upsert (:457071-457098), as do AddFellow @0x005B94D5 and RemoveFellow @0x005B96EE (lane B §2.10). FA2 stores _evenXpSplit from the full update and never recomputes it on ApplyUpdateFellow/ApplyQuit/ ApplyDismiss. FA4's share-percentage column branches on exactly this field (lane B §2.9). Against ACE it is largely masked — RemoveFellowshipMember and AddFellowshipMember both finish with UpdateAllMembers(), a FullUpdate to everyone (references/ACE/Source/ACE.Server/Entity/Fellowship.cs:179,219-227) — but the retail mechanism is absent, and the owner is where retail keeps it.

SF-4 — Retail's locked/departed admission gate on the upsert path is not modelled. Fellowship::UpdateFellow falls through to Fellowship::AddFellow @0x005B9480 when the guid is absent (@0x005B976F), and AddFellow refuses a guid while _locked unless it is in _fellows_departed within 900 s (lane B §2.11, @0x005B94A5). FA2's ApplyUpdateFellow always inserts, and ApplyFullUpdate discards update.Departed entirely (RuntimeFellowshipState.cs:67-84 — field 8 of 0x02BE per lane B §3.9). The insert-a-new-member branch IS live against ACE (AddFellowshipMember sends UpdateFellow to existing members before the FullUpdate, Fellowship.cs:161-163), so this is reachable, not theoretical.

SF-5 — AllegianceProfileLookups is re-implemented rather than reused. RuntimeAllegianceState's TryGetMember/TryGetPatron/GetVassals (:214-290) duplicate FA1's ClientCommandResponses.AllegianceProfileLookups (:250-294) line for line. They agree today — I diffed both against AllegianceHierarchy::GetPatron @0x005B6DD0 (:453991-454011) and the §4.4 reversal rule and both are correct — but two copies of a retail walk is the shape that drifts. AllegianceProfileLookups is private static; promoting it to internal (or public) lets Runtime call the one implementation.

SF-6 — RuntimeStateCheckpoint's new defaulted snapshots carry null strings. GameRuntimeViews.cs:241-245 defaults Fellowship/Allegiance to default, whose Name/AllegianceName are null (not string.Empty — the owners' own initialisers are correct, RuntimeFellowshipState.cs:41, RuntimeAllegianceState.cs:49). Only test-constructed checkpoints hit it (GameRuntimeContractTests.cs:150 is the sole positional site), and the trace recorder only reads scalars (GameRuntimeEvents.cs:184-189), so nothing NREs today. Worth a non-null default.

Observations (no action requested). RuntimeFellowMemberSnapshot.ShareLoot is exposed as bool while lane B §4.1's recommendation is "model as a raw uint" — the predicate is right (!= 0, never == 1, RuntimeFellowshipState.cs:291-293, pinned by ShareLoot_ReadsTheRawWireBitAsNonZero_NeverEqualsOne) and the raw value is retained in the owner, so this is a view-shape preference, not a defect. IRuntimeFellowshipView has no member enumeration (only TryGetMember(guid) + MemberCount), which FA4's roster list box will need.

---

3. What verified clean

3.1 Fellowship lifecycle rules — every rule re-derived against the decomp

Rule	FA2	Retail
Full update REPLACES	ApplyFullUpdate clears then refills, sets _isInFellowship (:67-84)	Handle_Fellowship__FullUpdate @0x005693C0: allocate CFellowship if absent, then Fellowship::operator= (:374037-374071)
Incremental UPSERTS by guid	_members[update.MemberGuid] = update.Member (:92-101)	Fellowship::UpdateFellow @0x005B9730 → Fellow::operator= on hit, AddFellow on miss (:457071-457098)
SELF quit clears the WHOLE snapshot	ApplyQuit, quitterGuid == selfGuid → ClearLocked() (:110-124)	Handle_Fellowship__Quit @0x00569E90: arg2 != player_id → RemoveFellow, else DeleteFellowship (:374914-374950)
Other-quit removes ONE	_members.Remove(quitterGuid)	same site
Dismiss identical to quit	ApplyDismiss (:130-144)	Handle_Fellowship__Dismiss @0x00569F10 is byte-identical (:374953-374985)
Disband always clears	ApplyDisband (:147-151)	Handle_Fellowship__Disband @0x00569E70 → DeleteFellowship (:374903-374910)

The if (!_isInFellowship) return; guards on the three incremental mutators are strictly defensive: retail passes a possibly-null m_pFellowship straight into Fellowship::IsFellow/RemoveFellow with no guard, so the equivalent retail state faults rather than doing something different. ACE never reaches it (Player.LogOut_Inner → FellowshipQuit(false), references/ACE/.../WorldObjects/Player.cs:531-532, so a reconnect is never mid-fellowship; and HandleFellowshipUpdateRequest sends a FullUpdate before any vitals stream, Player_Fellowship.cs:142-149).

The leader hand-off rule is exact. RequiresLeaderHandoffBeforeQuit (RuntimeFellowshipState.cs:172-193) returns true only when !disband && _isInFellowship && _leaderGuid == selfGuid and a non-self member exists. Retail's Quit button, gmFellowshipUI::ListenToElementMessage case 8 (:156425-156444):

0049034b  case 8:
00490353      if (m_pFellowship_1 != 0)
0049035d          if (m_pFellowship_1->_leader == GetPlayerID())
00490361              eax_18 = Fellowship::GetNonLeaderFellowID(m_pFellowship_1);
00490368              if (eax_18 != 0) AssignLeadershipToFellow(this, eax_18);
004903f1      CM_Fellowship::Event_Quit(0);

and case 0xC (Disband) is CM_Fellowship::Event_Quit(1) with no hand-off (:156475-156479). FA2 collapses the two retail buttons into one Quit(disband) and gates the hand-off on !disband — behaviourally identical. Fellowship::GetNonLeaderFellowID @0x005B9200 (:456723-456770) walks the hash table returning the first key != _leader; FA2 skips selfGuid, which equals _leaderGuid on that branch. Equivalent modulo iteration order, which retail does not define either.

Ordering is preserved on both hosts. Direct sends 0x0290 then 0x00A3 inline (DirectGameRuntimeCommandAdapter.cs Quit); App publishes two bus messages under one lock (LiveSessionCommandRouter.Publish, :293-300), so FellowshipAssignNewLeaderRuntimeCmd cannot be reordered after FellowshipQuitRuntimeCmd.

IsFull >= 9 — verified by absence. No FA2 code encodes a fellowship capacity anywhere (grep for IsFull returns only unrelated IsFullyConstrained/OutsideIsFullScreen/IsFullyResident), and RuntimeFellowshipSnapshot exposes MemberCount without an IsFull. Lane B §7.1's byte-decoded cmp [ecx+0x14],9 / sbb / inc result has nothing to be wrong about yet; FA4's UpdateButtons port is where it lands.

3.2 The shared 0x027C registration — the folding claim is correct and the live output is byte-identical

GameEventDispatcher.Dispatch (:95-117) is a single _handlers.TryGetValue → registration.Handler(envelope); Register (:57-76) writes _handlers[type] = node, i.e. it REPLACES. The seam doc §2.3's "both fire" claim is wrong and the implementer's correction is right — a literal second registrar.Register(AllegianceInfoResponse, …) would have silently killed the live @allegiance info output.

The folded handler (GameEventWiring.cs, AllegianceInfoResponse registration) keeps the pre-existing three lines verbatim — parse, if (info is null) return;, foreach (FormatAllegianceInfoLines) chat.OnSystemMessage(line, chatType: 0u) — and only appends the self-gated callback afterwards. One parse feeds both; there is no double-parse divergence and no reordering of the chat emission. Pinned by WireAll_AllegianceInfoResponse_SelfGated_FiresOnlyForOwnGuid, which asserts chatLines > 0 on both the self and the other-player response and observed == null only on the latter. (Note this verdict is about the fold; whether the callback should exist at all is MF-2.)

Minor: the gate is playerGuid is not null && info.Value.TargetGuid == playerGuid(), with no playerGuid() != 0 clause. ACE always writes a real guid (GameEventAllegianceInfoResponse.cs:9-11), so it is unreachable, but a != 0 clause would be free.

3.3 D4's 0x00A6 — present, generation-gated, not fired

IRuntimeFellowshipCommands.SetPanelOpen (GameRuntimeCommands.cs:341-343) is implemented on both adapters (DirectGameRuntimeCommandAdapter.cs:941, CurrentGameRuntimeCommandAdapter.cs:934), both behind the generation Validate gate, and reaches WorldSession.SendFellowshipUpdateRequest → SocialActions.BuildFellowshipUpdateRequest. A whole-src grep for SetPanelOpen finds no caller other than the unrelated ToolbarController.SetPanelOpen(uint panelId, bool open). No premature send. The same holds for IRuntimeAllegianceCommands.SetUpdateSubscription (0x001F) — declared, implemented, uncalled.

3.4 Wiring symmetry

Both LiveSocialSessionBindings construction sites are updated in the same commit with identical named arguments — src/AcDream.App/Net/LiveSessionRuntimeFactory.cs:261-263 (Fellowship: _domain.Runtime.FellowshipOwner, Allegiance: _domain.Runtime.AllegianceOwner) and src/AcDream.Headless/Hosting/HeadlessSessionHost.cs:785-787 (Fellowship: Runtime.FellowshipOwner, Allegiance: Runtime.AllegianceOwner). There is still exactly one GameEventWiring.WireAll call site (LiveSessionEventRouter.cs:234), so both hosts get the same registration.

The self-guid used for the quit/dismiss self-vs-other split resolves to the same owner on every path: the router uses inventory.PlayerGuid(), bound to () => _player.Identity.ServerGuid in App (LiveSessionRuntimeFactory.cs:277) and () => Runtime.PlayerIdentity.ServerGuid in Headless (HeadlessSessionHost.cs:745); Direct uses _runtime.PlayerIdentity.ServerGuid; App's adapter uses _view.Lifecycle.PlayerGuid, which GameRuntime fills from PlayerIdentity.ServerGuid (GameRuntime.cs:484-488). One source.

The two adapters' zero-guid rejection paths look different (EmitUnsupported(...,Rejected,guid) vs EmitResult(...,Rejected,guid)) but are semantically identical — both call EventSink.EmitCommand(domain, op, status, primaryObjectId) and return Result(status, primaryObjectId); EmitResult merely also passes text: null (DirectGameRuntimeCommandAdapter.cs:1355-1383).

IRuntimeEventObserver is untouched — the 369729f0 diff of GameRuntimeEvents.cs adds only two RuntimeCommandDomain ordinals and six trace-string lines; the interface (:100-118) is unchanged, so the five bot policies and the trace recorder still compile. This honours D2.

The Runtime-only assembly guard still holds: GameRuntimeTests.cs:174-181 asserts no AcDream.App/Silk.NET assembly loads, and both new owners live in AcDream.Runtime depending only on AcDream.Core.Net.Messages types. GameRuntimeContractTests.cs gained both new types to its owned-type list.

3.5 TS-81

The register row is honest and the mechanism claim is verifiable. At gmAllegianceUI::RecvNotice_AllegianceLogin @0x00492220 the two candidate strings really do resolve through mislabelled vtable-slot symbols:

00492278      if (arg3 == 0)
00492281          var_48_1 = &gmAllegianceUI::`vftable'.RecvNotice_PrevSpellTab;
00492278      else
0049227a          var_48_1 = &gmAllegianceUI::`vftable'.RecvNotice_UpdateSpellComponents;
00492286      AC1Legacy::PStringBase<char>::PStringBase<char>(&arg3, var_48_1);

(:158434-158439) — a PStringBase<char> constructed from what BN typed as two unrelated vtable entries. Refusing to invent English here is correct. ApplyLoginNotification does bump the revision (RuntimeAllegianceState.cs:131-135), pinned by Revision_IsMonotonicAcrossEveryEventKind. TS-80's narrowing is also accurate: Create(gen, name, shareXp) takes the flag but no caller reads FellowshipShareXP into it.

3.6 Snapshot immutability, revision monotonicity, J-owner template

Snapshots are readonly record structs of scalars plus member value-copies; the parsed IReadOnlyList<AllegianceMemberRecord> stored by ApplyUpdate/ApplyInfoResponseSelf is a freshly allocated list per parse (ClientCommandResponses.ReadAllegianceProfileBody, :518-519) held by no one else, so there is no aliasing path back into the owner. Every mutator bumps a monotonic long; the no-change paths (ClearLocked when already empty, Remove returning false) deliberately do not, which is correct for a poll contract.

The 8-edit template is complete and the teardown maths is right: GameRuntimeTeardownStage renumbers IdentityDisposed 1<<9→1<<11 and EntityObjectsDisposed 1<<10→1<<12 (in-memory flags only — no serialized consumer), TeardownStageCount 11→13, and the stage masks at GameRuntime.cs:716-735 compose correctly, with 10/11/12 expressed as Complete & ~… of exactly the not-yet-run stages. RuntimeGenerationResetStage stays contiguous (Fellowship = 12 before BeginEntityRetirement = 13), which Advance's state.Stage++ requires. Both fault-injection construction points were added and are covered.

3.7 Test run

dotnet test tests/AcDream.Runtime.Tests --no-build -c Release --filter "FullyQualifiedName~Fellowship|FullyQualifiedName~Allegiance|FullyQualifiedName~GenerationReset" → 43 passed, 0 failed, 0 skipped on the committed Release binaries. The ledger's 13,201/4/0 full-suite claim was not independently re-measured (no build permitted for this review).

---

4. Disposition summary

#	Severity	Finding
MF-1	MUST-FIX	Allegiance survives generation reset; retail clears at OnEndCharacterSession, the cited precedent clears, the graphical host can enter a different character in the same process, and the behavior is test-pinned
MF-2	MUST-FIX	0x027C seeds the owner; retail's handler is print-only over a stack temporary. Carries a stale-Rank second-order defect
SF-1	SHOULD-FIX	Unconditional delegate holes remove 9 event types from the unhandled-count diagnostic
SF-2	SHOULD-FIX	Disposed check outside the lock in both owners (ownership-ledger convergence risk)
SF-3	SHOULD-FIX	RecalculateEvenXPSplitting not modelled on upsert/removal
SF-4	SHOULD-FIX	Locked/departed admission gate + 0x02BE field 8 not modelled
SF-5	SHOULD-FIX	AllegianceProfileLookups duplicated in Runtime instead of reused
SF-6	SHOULD-FIX	Defaulted checkpoint snapshots carry null Name/AllegianceName