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

# Campaign FA slice FA1 — MECHANISM-FAITHFULNESS review

**Date:** 2026-08-12. **Lens:** mechanism faithfulness (is every byte and
every rule right?). **Mode:** read-only; this doc is the only file written.

**Target:** `7be86f47` (builders), `6bedbc47` (parsers), `5f9aa16f`
(WeenieError), `4281750b` (delete `AllegianceTree`), ledger `ee1124ca`.

**Contract:** `docs/plans/2026-08-11-fellowship-allegiance-campaign.md`
slice FA1 + D3/D5/D6/D9, with
`docs/research/2026-08-11-fa-fellowship-wire.md` (lane B) and
`docs/research/2026-08-11-fa-allegiance-wire.md` (lane C) as ground truth.

**Primary sources re-read independently for this review** (not taken on
the lane docs' word): `docs/research/named-retail/acclient_2013_pseudo_c.txt`
(`Fellow::UnPack @0x005B9AD0`, `Fellowship::UnPack @0x005B94F0`,
`PackableHashTable<unsigned long,Fellow>::UnPack @0x00569A90`,
`CM_Fellowship::DispatchUI_UpdateFellow @0x006A6700`,
`CM_Fellowship::Event_Create @0x006A67A0`,
`AllegianceHierarchy::UnPack @0x005B7520`,
`AllegianceHierarchy::Add @0x005B6E90`,
`AllegianceProfile::UnPack @0x005B6B90`, the `0x20` dispatch case at
`0055b5dd`, `ClientCommunicationSystem::HandleFailureEvent @0x00571990`),
`docs/research/named-retail/acclient.h:2979-2994` (`AllegianceVersion`),
`docs/research/named-retail/symbols.json`, and the ACE writers
`references/ACE/Source/ACE.Server/Network/Structure/AllegianceHierarchy.cs`,
`.../AllegianceData.cs`, `.../AllegianceProfile.cs`,
`.../GameEvent/Events/GameEventAllegianceUpdate.cs`.

---

## VERDICT: **APPROVE-WITH-FIXES**

Every wire layout in this slice is byte-correct against the retail
decompilation, and both premise-contradiction calls are **independently
verified correct from primary source** (§2). The fixes below are two
rule/coverage gaps and a set of smaller fidelity items; none of them
invalidates a landed byte vector, and all of them are unreachable against
ACE today — which is exactly why they need pinning now rather than
discovering them against a non-ACE server or a hand-built FA2 fixture.

**MUST-FIX: 2. SHOULD-FIX: 5. Nits (non-blocking): 5.**

---

## 1. MUST-FIX

### MF-1 — `AllegianceHierarchy::Add`'s FOURTH rejection rule (`_id == 0`) is not modeled

`src/AcDream.Core.Net/Messages/ClientCommandResponses.cs:501-524` models
three of the four rejection rules in
`AllegianceHierarchy::Add @0x005B6E90`. The whole function body in retail
is wrapped in `if (_id != 0)`:

```
005b6e96      uint32_t _id = arg3->_id;
005b6e9e      if (_id != 0)          <-- every success path is inside this
              ...
005b6ecd      return 0;              <-- _id == 0 falls straight out
```

and the caller (`005b779d`) turns any `Add` failure into `return 0` from
`UnPack`, i.e. the whole message is discarded. Lane C §4.4's own
pseudo-code lists it first (`if (data._id == 0) return 0;   // reject`).

acdream reads the monarch at `:505` and each record at `:512` with no
`CharacterId != 0` check, so:

* a profile whose **monarch** record has id 0 is accepted where retail
  discards it, and
* every subsequent record naming `treeParent = 0` is then admitted by
  `knownIds.Contains(0)` — where retail rejects `treeParent == 0`
  unconditionally (`005b6ee5`: `esi = (arg2 != 0) ? Search(...) : nullptr`,
  then `esi != 0` is required).

One guard fixes both: reject the whole message when any record's
`CharacterId == 0`. Add the boundary test beside the existing three at
`tests/AcDream.Core.Net.Tests/Messages/AllegianceProfileVersionGateTests.cs:312-353`.

Unreachable against ACE (`AllegianceData.cs:69` always writes a real
guid) — the same "correct only because ACE is generous" class lane C §0
warns about for the version gates, which this slice otherwise closed.

### MF-2 — `0x001F AllegianceUpdateRequest` builder is missing

`src/AcDream.Core.Net/Messages/AllegianceRequests.cs:34-83` ships
Swear (`0x001D`), Break (`0x001E`) and the new Kick alias — and nothing
else. There is no `0x001F` builder anywhere in the tree (repo-wide grep
for `0x001F` / `AllegianceUpdateRequest` over `src/**/*.cs` returns only
`PropertyBool.AllegianceUpdateRequest`, an unrelated property id).

`0x001F` is the allegiance panel's subscribe/unsubscribe toggle — the
exact structural twin of the fellowship `0x00A6` this slice *did* repair
and rename. Lane C §1.2 pins all four retail send sites
(`gmAllegianceUI::PostInit` tail `@0x004911C6` → 1,
`RecvNotice_PlayerDescReceived @0x00490D59` → 1,
`OnVisibilityChanged` visible `@0x004912DD` → 1, hidden `@0x00491311` → 0)
and lane C §7.1 numbers it #3 of the six messages the minimum-viable
panel needs, with the explicit instruction "ACE ignores the value but
retail servers do not; send it correctly."

FA1 is the Core.Net truth slice and FA2 (Runtime owners + typed commands)
lands before FA5; leaving this out pushes a `AcDream.Core.Net` builder
addition into a Runtime or panel slice. Six lines plus a golden vector
(`[u32 0xF7B1][u32 seq][u32 0x1F][u32 on]`, total `0x10` per lane C §3.2).

---

## 2. The two premise-contradiction calls — BOTH VERIFIED CORRECT

I re-derived both from primary source rather than accepting the commit
messages. Both stand.

### (a) The 8 fellowship `WeenieError` ids genuinely have no retail text — `5f9aa16f` is right, D9's premise was wrong

D9 asserted "the 8 missing fellowship WeenieError strings are added in
FA1 … all resolve from the DAT string tables, never invented." The
implementer refused and documented absence instead. Verified:

1. **Case-label walk.** In `HandleFailureEvent @0x00571990`
   (`acclient_2013_pseudo_c.txt:382616`+) the label sequence is
   `case 0x413: → case 0x414: → case 0x416: → case 0x41d: → case 0x41e:
   → case 0x41f:` — **no label for `0x417`–`0x41C`** — and
   `case 0x4d9: → case 0x4da: → case 0x4dd:` — **no label for `0x4DB`/
   `0x4DC`**.
2. **The `else if` chain too.** `WeenieErrorMessages`' own class doc warns
   that five ids dispatch via `else if (arg2 == N)` above the switch, so
   a case-label-only sweep would be unsound. The function contains exactly
   seven such comparisons — `0x43`, `0x3f7`, `0x3e`, `0x23`, `0x36`,
   `0x4e8`, `0x48a`, `0x408`, `0x3ee`, `0x4f` — none of them ours.
3. **Whole-file sweep.** `\b0x417\b` … `\b0x41c\b`, `\b0x4db\b`,
   `\b0x4dc\b` across all 1.4 M lines return only unrelated hits: struct
   field offsets in three `*(uint16_t*)(ecx+0x418)` copy loops, and
   `[0x417]`/`[0x418]`/… array-index headers inside a `MeshBuffer`
   render-batch data dump at `.data 0x008872xx` / `0x008c4axx`. Nothing
   textual, nothing comparative.
4. **Decimal forms.** No `1047`–`1052`/`1243`/`1244` anywhere in the
   function's address range.
5. **No `default:`** in the switch, so an unmatched id produces no text at
   all — which is precisely what `Resolve()` already returns.

Conclusion: acdream's existing silence for `0x0417 FellowshipIgnoringRequests`
and `0x04DB FellowshipDeclined` (the two ACE actually sends) is
retail-faithful. Adding invented English would have been the exact
failure mode the table's no-default-case rule exists to prevent. The
conformance `[Theory]` at
`tests/AcDream.Core.Tests/Chat/WeenieErrorMessagesTests.cs:390-393` is the
right artifact. **No fix owed; no register row owed** (silence *is* the
retail behavior, so there is no deviation to record).

### (b) `0x0275` is client-authored — a receive parser was never the ask, and D6's need is satisfied

Verified: `0x0275` is a C→S GameAction sub-opcode
(`CM_Character::Event_ConfirmationResponse @0x006A1210`, buffer `0x18`;
consumed server-side by ACE's `GameActionConfirmationResponse`). Retail
never receives it. So "the missing third message of the triple" (D6)
could not have meant a parser.

`ClientCommandRequests.BuildConfirmationResponse` already existed pre-FA1
byte-for-byte (`git show 6bedbc47~1` — 24-byte body,
`[env][seq][0x0275][type][context][accepted]`, matching retail's `0x18`
allocation exactly). What was genuinely absent was the **typed
discriminator**, and `GameEvents.ConfirmationType`
(`src/AcDream.Core.Net/Messages/GameEvents.cs:552-561`) supplies it with
all seven values matching retail's
`ClientUISystem::Handle_Character__ConfirmationRequest @0x005640A0` switch
(symbol verified at that exact address) and ACE's enum.

**D6's FA4/FA5 flows are buildable on this today**: receive `0x0274` via
`ParseCharacterConfirmationRequest` (`:512`, `Type` as `uint` — cast to
the new enum), send via `BuildConfirmationResponse((uint)ConfirmationType.Fellowship, …)`,
receive `0x0276` via `ParseCharacterConfirmationDone` (`:533`). The
reinterpretation is sound.

---

## 3. SHOULD-FIX

### SF-1 — the monarch's `MayPassupExperience` must be forced false

`AllegianceHierarchy::UnPack`'s last act before returning success is
`AllegianceData::SetMayPassupExperience(&m_pMonarch->_data, 0)`
(`acclient_2013_pseudo_c.txt:454670`, `005b77b3`) — the monarch can never
pass up, whatever the wire bit says. Lane C §4.1 names this in the same
paragraph as the `HasPackedLevel`-absent rule that
`ClientCommandResponses.cs:564-565` *did* port; only one of the pair
landed. The field is public
(`AllegianceMemberRecord.MayPassupExperience`, `:201`), so FA5 could
render it wrong. Clear it on the monarch record at `:505-506`.

Inert against ACE (`AllegianceData.cs:76` never sets the bit for a
monarch), but it becomes live the moment the record is hand-built or a
non-ACE server is used.

### SF-2 — `ParseFellowshipDisband` rejects a non-empty body; retail never does

`src/AcDream.Core.Net/Messages/GameEvents.cs:749`:
`ParseFellowshipDisband(payload) => payload.Length == 0`. Retail's
`CM_Fellowship::DispatchUI_Disband @0x006A5E80` reads **only** the opcode
and then calls the handler — it never inspects or validates a trailing
byte. Encoding a length check retail does not perform means any future
non-empty body (an ACE change, a trailing pad) silently swallows the
disband and leaves FA2's roster stuck in a fellowship the server already
destroyed. The faithful contract is unconditional acceptance. The
matching test at
`tests/AcDream.Core.Net.Tests/Messages/FellowshipEventsTests.cs:197-201`
pins the unfaithful half and should flip with it.

### SF-3 — D5's `<<1` shape is not pinned at the `0x02C0` site

D5 requires the raw-uint `shareLoot` read at **both** message sites. The
mechanism is right — `ReadFellow` (`GameEvents.cs:777`, `shareLoot` at
`:786`) is shared by `ParseFellowshipFullUpdate` (`:661`) and
`ParseFellowshipUpdateFellow` (`:706`), and `FellowMember.ShareLoot`
(`:622`) is a `uint` with no `== 1` comparison anywhere in the tree. But
the tests pin `0x10` and `2` only at `0x02BE`
(`FellowshipEventsTests.cs:70,95`); the `0x02C0` fixture writes
`shareLoot = 0` (`:154`). Add the `<<1`-shape (`2`) assertion at the
`0x02C0` site so a future refactor that splits `ReadFellow` cannot
silently reintroduce a bool there.

Carry-forward for the FA2 reviewer: `!= 0` semantics are currently only
*documented* (`:606-609`) — nothing consumes `ShareLoot` yet. The
consuming comparison lands in FA2 and must be checked there.

### SF-4 — AP-90's register row now cites a deleted class

`docs/architecture/retail-divergence-register.md:298` (AP-90) reads
"… and its `AllegianceTree` is not wired into GameWindow". `4281750b`
deleted that class. The row itself is still valid (radar relationship
state is still not delivered), but the prose must be re-pointed at
`ClientCommandResponses.AllegianceProfileLookups` / the FA2 owner. The
register rule says the bookkeeping rides the same commit; this one
slipped.

### SF-5 — the "eleven gates" numbering in the code comments tops out at ten, and one lane citation does not exist

Two documentation-accuracy items that will cost a future auditor time:

* `ClientCommandResponses.cs:411-491` labels the gates "1/2, 3, 4, 5, 6,
  7, 8, 9, 10". The contract, the commit message and lane C all say
  **eleven**. All eleven *fields* are gated correctly (verified §4 below)
  — only the comment numbering is off, and it is the exact artifact
  someone would use to answer "are all eleven present?".
* `SocialActions.cs:184` cites "lane B §4.5, §12". Lane B has no §12 —
  the intended reference is master-table **row 12**
  (`Panel visibility → update request`).

---

## 4. Verified clean (re-derived, not taken on trust)

### 4.1 Golden byte vectors — all six independently re-derived, all correct

| Builder | Expected bytes (hand-derived from the cited retail sender) | Test | Verdict |
|---|---|---|---|
| `BuildFellowshipCreate(seq 7,"Team",true)` | `B1F70000 07000000 A2000000` + str16L`0400 54 65 61 6D 0000` + `01000000` = 24 B | `SocialActionsTests.cs:65-83` | ✔ |
| `BuildFellowshipCreate(seq 1,"X",false)` | 12 + 4 (str16L `0100 58 00`) + 4 = 20 B, tail `00000000` | `:85-95` | ✔ |
| `BuildFellowshipUpdateRequest(9,true)` | `…A6000000 01000000` | `:130-146` | ✔ |
| `BuildFellowshipAssignNewLeader(2,0x50001234)` | `…90020000 34120050` | `:151-168` | ✔ |
| `BuildFellowshipChangeOpenness(4,false)` | `…91020000 00000000` | `:173-190` | ✔ |
| `BuildSwear/BuildBreak/BuildKick` | `…1D000000 AAAA0000` / `…1E000000 BBBB0000` / `…1E000000 42000050` | `AllegianceRequestsTests.cs:39-90` | ✔ |

The `0x00A2` repair is confirmed at the strongest possible provenance:
`CM_Fellowship::Event_Create @0x006A67A0` allocates `strPackSize + 0x10`,
stores `0xa2` at `006a6809`, packs the string at `006a6828`, then
`*(uint32_t*)var_c = arg2` at `006a6835` — **one trailing u32 shareXP and
no openness field**. The prior two-byte `openness`/`shareXp` shape (and
the test that pinned it) was exactly the inversion lane B §5.2(a)
described.

`PackString16L` (`SocialActions.cs:389-403`) is Windows-1252 with the pad
computed over `2 + length` — matching retail's `PStringBase::Pack`, ACE's
`WriteString16L`, and the reader `ReadString16L`
(`GameEvents.cs:913-926`). No endianness, padding, or encoding slip
anywhere in the set.

Byte-write-vs-u32-write equivalence (`body[12] = 0|1` into a zeroed
16-byte buffer) is byte-identical to retail's full-word store for these
0/1 payloads — see nit N-2.

### 4.2 `Fellow` record layout (the load-bearing one)

`Fellow::UnPack @0x005B9AD0` reads, in order: `_cp_cache`, `_lum_cache`,
`_level`, `_max_health`, `_max_stamina`, `_max_mana`, `_current_health`,
`_current_stamina`, `_current_mana`, `_share_loot`, then `str16L _name`
(min size `0x28`). `GameEvents.ReadFellow` (`:777-793`) is field-for-field
identical. ✔

### 4.3 `0x02BE` field order and the hash-table header

`Fellowship::UnPack @0x005B94F0`: `_fellowship_table` → `_name` →
`_leader` → `_share_xp` → `_even_xp_split` → `_open_fellow` → `_locked` →
`_fellows_departed`, then returns — it never reads field 9 (locks).
`ParseFellowshipFullUpdate` (`GameEvents.cs:637-681`) matches exactly,
**including** the deliberate non-parse of field 9, which is the
retail-faithful choice (lane B §3.9 suggested reading it; retail does
not, and lane B's own U3 flags the struct width as unverified — the
implementer's stop-and-document call is correct and needs no register
row).

Header: `PackableHashTable<unsigned long,Fellow>::UnPack @0x00569A90`
reads one u32 and splits `_table_size = v >> 16`, `count = v & 0xFFFF` —
so the wire is `[u16 count][u16 numBuckets]` LE, which is what the parser
reads for both the member table (`:653-654`) and the departed table
(`:670-671`). ✔

### 4.4 `0x02C0` is guid-first — the Chorizite disagreement independently re-resolved

`CM_Fellowship::DispatchUI_UpdateFellow @0x006A6700`:

```
006a6726  cond = *(uint32_t*)eax_3 == 0x2c0;      // opcode at +0
006a673b  uint32_t edi = *(uint32_t*)(eax_3 + 4); // MEMBER GUID at +4
006a6763  Fellow::UnPack(&var_30, &arg2, …);      // Fellow from +8
006a676c  uint32_t ecx_4 = *(uint32_t*)eax_7;     // updateType last
```

Retail puts the guid first. `ParseFellowshipUpdateFellow`
(`GameEvents.cs:700-712`) reads guid → `Fellow` → `updateType`. ✔ The
lane-B three-source resolution (retail + ACE + holtburger over
Chorizite's generated shape) is confirmed at its retail end.

### 4.5 The eleven version gates — every threshold and the ORDER

Re-derived from `AllegianceHierarchy::UnPack @0x005B7520` and the
`AllegianceVersion` enum (`acclient.h:2979-2994`). Order on the wire is
**not** monotonic in version — officer titles (v9) precede the pools
block (v2) — and the implementation follows the wire, not the numbering:

| # | Field | Retail predicate (address) | `ClientCommandResponses.cs` | ✔ |
|---|---|---|---|---|
| 1 | officers `PHashTable<u32,u32>` | `m_oldVersion >= 6` (`005b7570`/`005b7585`) | `:416-425` | ✔ |
| 2 | legacy spokesperson 4-byte skip | `1 <= v < 6` (`005b759b`) | `:426-429` | ✔ |
| 3 | officer titles `PSmartArray<PString>` (bare i32 count) | `>= OfficersTitlesAdded(9)` (`005b75b4`) | `:434-439` | ✔ |
| 4–7 | monarch/spokes broadcast time+today ×4 | `>= PoolsAdded(2)` (`005b75e0`) | `:442-448` | ✔ |
| 8 | `m_motd`, `m_motdSetBy` | `>= MotdAdded(3)` (`005b7645`) | `:453-457` | ✔ |
| 9 | `m_chatRoomID` | `>= ChatRoomIDAdded(4)` (`005b7696`) | `:461-462` | ✔ |
| 10 | `m_BindPoint` (32-byte Position) | `>= Bindstones(7)` (`005b76b2`) | `:468-472` | ✔ |
| 11 | `m_AllegianceName` + `m_NameLastSetTime` | `>= AllegianceName(8)` (`005b76d1`) | `:477-481` | ✔ |
| 12 | `m_isLocked` | `>= LockedState(10)` (`005b770d`) | `:485-486` | ✔ |
| 13 | `m_ApprovedVassal` | `>= ApprovedVassal(11)` (`005b7728`) | `:490-491` | ✔ |

`BannedCharactersAdded(5)` gates nothing — confirmed, and pinned by the
negative test `VersionGate_4to5_BannedCharactersAddedGatesNothing`.

**Boundary tests sit on the boundaries.** Every gate has an `N-1`/`N`
fixture pair: 0→1, 1→2, 2→3, 3→4, 4→5 (negative), 5→6, 6→7, 7→8, 8→9,
9→10, 10→11
(`AllegianceProfileVersionGateTests.cs:152-308`). For the gates whose
fields are not surfaced (pools, bind point, officers, titles) the
assertion is the monarch record surviving intact — which IS a real
structural proof here, because the fixture writer
(`BuildProfileWire`, `:40-134`) applies the gate conditions
independently of the parser: a wrong threshold would consume or skip
bytes the writer did not emit and garble every field after it.

Cross-checked against ACE's writer
(`AllegianceHierarchy.cs:140-155`): identical field order, and
`oldVersion = 0x000B` always (`:50`) — so these gates are inert against
ACE and the live `@allegiance info` path is unchanged, exactly as
intended.

### 4.6 `AllegianceData` field order and `AllegianceProfile`/`0x0020` framing

`AllegianceData` per lane C §4.1, cross-checked against ACE
`AllegianceData.cs:95-117`: id, cpCached, cpTithed, bitfield, u8 gender,
u8 heritage, u16 rank, [u32 level if `HasPackedLevel`], u16 loyalty,
u16 leadership, [8 bytes either branch], str16L name.
`ReadAllegianceData` (`:532-571`) matches. ✔

`AllegianceProfile::UnPack @0x005B6B90` = `totalMembers`, `totalVassals`,
hierarchy — matches `:406-409`. ✔
The `0x20` dispatch case (`0055b5dd`-`0055b607`) reads one u32 and then
`AllegianceProfile::UnPack`, and ACE's `GameEventAllegianceUpdate.cs:22-25`
writes `rank` then the profile — so `ParseAllegianceUpdate`'s
rank-leading + shared-body split (`:375-391`) is right, as is the
guid-leading `0x027C` sibling. Sharing one `ReadAllegianceProfileBody` is
exactly lane C §7.2's reuse verdict honored. ✔

### 4.7 Tree rules — three of four correct, and the reversal test pins ORDER

Orphan / self-parent / duplicate all match `Add`'s semantics:

* orphan — retail `esi = (arg2 != 0) ? Search(arg2, monarch) : nullptr;
  if (esi == 0) return 0` ≡ `!knownIds.Contains(parentGuid)` (`:514`);
* self-parent — retail `esi->_data._id != _id` required, and `esi` was
  found *by* `treeParentId`, so it is `treeParentId == _id` ≡
  `parentGuid == record.CharacterId` (`:515`);
* duplicate — retail `Search(_id, monarch) == 0` required ≡
  `knownIds.Contains(record.CharacterId)` (`:516`);
* all three `return null`, i.e. whole-message discard, matching
  `UnPack`'s `return 0` at `005b779d`. ✔

The record loop's first-record-has-no-`treeParent` shape is confirmed at
`005b776e` (`if (ebp_1 != 0) { read treeParent }`) and matches `:505-512`.
✔ (The fourth rule is MF-1.)

**Sibling reversal — the test pins the ORDER, not just membership.**
`FindVassals` (`:288-294`) walks the record list backwards, which is the
correct model of retail's push-front insert (`node->_peer = parent->_vassal;
parent->_vassal = node;` at `005b6f15`-`005b6f38`) followed by a
`GetFirstVassal`/`GetNextVassal` walk.
`TreeAssembly_SiblingOrder_ReversesOnAssembly`
(`AllegianceProfileVersionGateTests.cs:371-396`) asserts the exact
sequence `{"VassalC","VassalB","VassalA"}` against wire order A,B,C. ✔
Note this changes the live `@allegiance info` vassal render order (it was
forward before FA1) — the new order is the retail one; lane C §9 U3 flags
a side-by-side eyeball as the closing check.

### 4.8 Dead opcodes `0x01C9`/`0x01CA`

`ParseFellowshipFellowUpdateDone` / `…StatsDone`
(`GameEvents.cs:759-775`) return a non-nullable record and cannot fail:
empty payload → `RawValue = null`, trailing u32 → captured. Both cases
are tested (`FellowshipEventsTests.cs:205-233`). Nothing user-visible is
possible — neither is registered in `GameEventWiring.WireAll` (grep for
`Fellowship` there returns nothing), and `RawValue` has no consumer.
Matches lane B §2.7's parse-and-ignore instruction and its BN-zero-fold
caution (payload tolerated, not assumed empty). ✔

### 4.9 Retail anchors in code comments — spot-check (10, not 5)

Resolved against `symbols.json` (exact-address match unless noted):

| Anchor cited in code | Result |
|---|---|
| `gmFellowshipUI::CreateFellowship @0x0048F730` | exact ✔ |
| `gmFellowshipUI::OnVisibilityChanged @0x0048E460` | exact ✔ |
| `Event_AssignNewLeader @0x006A5F70` | exact (`CM_Fellowship::`) ✔ |
| `Event_ChangeFellowOpeness @0x006A6040` | exact (`CM_Fellowship::`) ✔ |
| `AssignLeadershipToFellow @0x0048F1E0` | exact ✔ |
| `Fellow::Pack @0x005B9A10` / `UnPack @0x005B9AD0` | exact ✔ |
| `AllegianceHierarchy::Add @0x005B6E90` | exact ✔ |
| `Handle_Character__ConfirmationRequest @0x005640A0` | exact (`ClientUISystem::`) ✔ |
| `gmAllegianceUI::CloseKickConfirmationDialog @0x00490B00` | exact ✔ |
| `gmFellowshipUI` Quit button case 8 `@0x0049034B`; `Event_BreakAllegiance @0x006A69DA` | instruction-level, correctly inside `gmFellowshipUI::ListenToElementMessage @0x004901C0` and `CM_Allegiance::Event_BreakAllegiance @0x006A6980` ✔ |

No misattributed anchor found.

### 4.10 Other contract items

* All **11 unwired S→C parsers** are present (fellowship `0x00A3`,
  `0x00A4`, `0x01C9`, `0x01CA`, `0x02BE`, `0x02BF`, `0x02C0`; allegiance
  `0x0003`, `0x0020`, `0x01C8`, `0x027A`), and all 11 ids exist in
  `GameEventType`. ✔
* `AllegianceTree` deletion is clean — no production or test reference
  survives (the one `AllegianceTree` hit in `ChatChannelInfoTests.cs:28`
  is an unrelated test-method name). Lane C §7.3's DELETE verdict
  honored. ✔ (See SF-4 for the register prose.)
* Test fixtures are generated by `AceWireWriter`, a line-for-line mirror
  of ACE's `Extensions.cs` writer — provenance is the server's own
  algorithm, not hand-typed hex. ✔
* No stale callers of the renamed/re-signatured builders remain. ✔

---

## 5. Nits (non-blocking; listed for completeness, no action required)

* **N-1** — Retail degrades *gracefully* on a short legacy blob (each
  gated read is additionally guarded by "≥4 bytes remain", e.g.
  `005b759b`, `005b75fc`); acdream throws `FormatException` and discards
  the message instead. Only reachable on a truncated pre-v11 blob, which
  ACE cannot produce.
* **N-2** — `BuildFellowshipQuit`/`BuildFellowshipUpdateRequest`/
  `BuildFellowshipChangeOpenness` write a single byte where retail writes
  a full u32. Byte-identical for the 0/1 payloads these carry (zeroed
  buffer), and blessed by lane B §5.2 — noted only so nobody "fixes" it
  into a behavior change.
* **N-3** — Retail's record count is a **signed** `int16_t`
  (`005b7546`: `int16_t i = ecx;` … `if (i > 0)`), so a header with the
  high bit set reads as zero records in retail and as up to 32 767
  records in acdream. Bounded and unreachable against ACE.
* **N-4** — `GameEvents.ParseConfirmationResponse` (`:581`) is by
  construction unreachable in production (nothing receives `0x0275`); its
  only consumer is `ConfirmationTripleTests`. Justified in its own doc
  comment as a round-trip conformance mechanism, and it is the cheapest
  way to prove the builder against a second implementation — but it is
  new never-called code in a slice whose D3 rule is "connected, repaired,
  or deleted — never trusted", so FA2 should either route it or leave the
  doc comment intact as the standing justification.
* **N-5** — `4281750b`'s commit message repeats lane C §0's "~1000×"
  figure for the deleted `AllegianceMath.ComputePassup`. The actual error
  is roughly 40× at maxed loyalty and *under*-states at low loyalty
  (`(50 + 22.5·291)/291 = 22.67` vs a true passup factor of ≈`0.53`).
  The DELETE verdict is unaffected and correct; the magnitude claim
  originates in the lane doc, not the implementer.

---

## 6. Note on evidence I could not produce

The slice's automated gate (Release build + full suite 13,149/4/0) is the
regression reviewer's lane. I did not build. The Debug test binaries in
this worktree predate FA1 (a `--no-build --filter` run over the six FA1
test classes matched only the 16 pre-existing `SocialActionsTests`/
`AllegianceRequestsTests` cases), so per the stale-build-artifact rule I
treat that run as evidence of nothing and reviewed every new test by
reading it instead. All test *logic* above is verified by inspection
against the primary sources cited.