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 + str16L0400 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.

---

7. Re-review of the fix round — 2026-08-12

Fix commits: ed308087 (code + tests), 511ba6e5 (docs).

VERDICT: CLOSED — all 7 findings (2 MUST-FIX, 5 SHOULD-FIX) verified fixed. No REOPEN.

One carry-forward for FA2's start (CF-1, §7.3) — not a reopen of any finding, and not a defect in the fix round: it is residual staleness the blast doc's own MF-2 enumeration did not reach.

7.1 Disposition of my findings

#	Finding	Disposition	Evidence
MF-1	Add's _id == 0 rule unmodeled	CLOSED	ClientCommandResponses.cs:509-510 rejects a zero-id monarch before it is assigned; :533 adds record.CharacterId == 0u to the child-record guard. Both return null = whole-message discard, matching 005b6e9e→005b6ecd. treeParent == 0 is now provably fatal for every non-monarch record: knownIds seeds from a monarch id that cannot be 0, so Contains(0) is always false. Three boundary tests added (AllegianceProfileVersionGateTests.cs:355-405: zero-id monarch, zero-id child, zero treeParent), each asserting null.
MF-2	0x001F AllegianceUpdateRequest builder missing	CLOSED	AllegianceRequests.cs:40-53 (AllegianceUpdateRequestOpcode = 0x001Fu) + :93-102 (BuildAllegianceUpdateRequest). Re-derived from primary source: CM_Allegiance::Event_UpdateRequest @0x006A7260 allocates 0x10, stores 0x1f at 006a72ba (the cited anchor is the opcode store itself), and writes arg1 as a full u32 at 006a72cb — the builder's [0xF7B1][seq][0x1F][on] is byte-exact. Two golden vectors (on/off) at AllegianceRequestsTests.cs:92-127, both hand-derived and correct. All five anchors in the new doc comment resolve: 0x006A7260 exact; 0x004911C6 / 0x00490D59 / 0x004912DD / 0x00491311 inside gmAllegianceUI::PostInit, ::RecvNotice_PlayerDescReceived, and ::OnVisibilityChanged respectively. The ACE claim is accurate — GameActionAllegianceUpdateRequest.cs:12 reads the u32 and replies unconditionally.
SF-1	Monarch MayPassupExperience not force-cleared	CLOSED	ClientCommandResponses.cs:544-553: monarch = monarch.Value with { MayPassupExperience = false }, placed after the record loop and inside if (recordCount > 0) — the same position and guard as retail's 005b77a7/005b77b3 (if (m_pMonarch != 0) SetMayPassupExperience(…, 0)), and unreachable from the return null paths exactly as in retail. The fixture relocation is correct and necessary: the old legacy-compat test sat on the monarch, where the new clear would make "fallback fired" indistinguishable from "clear fired". It now carries a two-record wire (monarch bitfield 0xC, vassal bitfield 0x4) and asserts both halves separately; the decisive new test feeds the monarch bitfield 0x1C (the wire bit explicitly SET) and still asserts false.
SF-2	ParseFellowshipDisband validated a body length retail never inspects	CLOSED	GameEvents.cs:777 is now => true, with the rationale in its doc comment. Test flipped: ParseFellowshipDisband_NonEmptyBody_StillReturnsTrue (FellowshipEventsTests.cs:224-232).
SF-3	D5 <<1 shape unpinned at 0x02C0	CLOSED	ParseFellowshipUpdateFellow_ShareLootIsRawNotBool_D5 (FellowshipEventsTests.cs:169-195) writes shareLoot = 2 on the 0x02C0 leg and asserts == 2u / != 1u, mirroring the 0x02BE pin.
SF-4	AP-90 cites the deleted AllegianceTree	CLOSED (shared with blast MF-1 — see §7.2)
SF-5	Gate comment numbering stopped at ten; bogus "lane B §12" citation	CLOSED, and better than asked	ClientCommandResponses.cs:411-424 renumbers to the actual AllegianceVersion enum values rather than wire-appearance order, and states explicitly that the wire order is a different sequence. I re-checked all ten labels against acclient.h:2979-2994: SpokespersonAdded 1, PoolsAdded 2, MotdAdded 3, ChatRoomIDAdded 4, MultipleAllegianceOfficersAdded 6, Bindstones 7, AllegianceName 8, OfficersTitlesAdded 9, LockedState 10, ApprovedVassal 11 — every label now matches its enum member. Gate 5 (BannedCharactersAdded) is called out by name as real-but-gating-nothing, which is what made the old numbering appear to lose a gate. SocialActions.cs:184-185 now cites "master-table row 12".

No path I flagged was fixed by suppression, early return, or a narrowing guard; each is the retail mechanism ported at the site retail performs it.

7.2 Spot-verification of the blast doc's six dispositions

Item	Verdict
MF-1 / AP-90 re-point	✔ retail-divergence-register.md:298 re-points the evidence column at ClientCommandResponses.cs (AllegianceProfileLookups) and GameEvents.cs (fellowship parsers), keeps the deviation active rather than retiring it (correct — no live owner exists until FA2), and dates the edit. ClientCommandResponses.cs:250-295 is a valid range: the class opens at :250 and FindVassals is at :288.
MF-2 / four seam-map corrections	✔ all four applied as dated strike-through + addendum rather than silent rewrite (the right call for a committed research record): :791 allegiance-owner "wrapping AllegianceTree" and its AllegianceTree.cs:56-162 precedent both struck and re-pointed; :666 SetOpen → BuildFellowshipUpdate struck and re-pointed at BuildFellowshipChangeOpenness (0x0291) with the semantic-bug warning; the 4-arg BuildFellowshipCreate corrected in both places (:429 dimming discussion and :668 bot-command table); open question 8 struck and answered. I verified question 8's answer independently — PackString16L pads the record to a 4-byte multiple including its own u16 length, so 12 + name.Length is already aligned before the trailing u32, and ACE's BinaryReaderExtensions.ReadString16L:47 skips the identical CalculatePadMultiple(2 + length, 4). The answer is correct and the question is properly closed. Cited line numbers SocialActions.cs:144-155, :222-230, :389-403 all resolve.
MF-3 / D9 + slice-row annotation	✔ D9 (:103) and the FA1 slice-map row (:130) both struck and annotated with the shipped finding, each pointing at §2(a) of this doc and at the conformance [Theory]. The annotation correctly states that no register row is owed (acdream matches retail, so there is no deviation to record). The slice row also picks up 0x001F in its opcode list.
MF-4 / ledger arithmetic	✔ reconciled and now internally closed: 13,153 total = 4+916+1559+15+130+119+4856+877+4677 (I summed it: 13,153), minus 4 skips = 13,149 passed, matching the prior figure; the "+50" framing is replaced with the diff-verified +58 / −9 = +49, and the one-test residual is attributed to the §5 baseline being captured at a different point in history rather than papered over. That is an honest reconciliation, not a re-transcription.
SF-1 / two live-command pins	✔ ClientCommandResponsesTests.cs:317-390: a three-vassal test through FormatAllegianceInfoLines pinning the exact reversed print order (VassalC / VassalB / VassalA) — the pre-existing full-tree test had one vassal and could not distinguish direction — and a GameEventWiring-layer test proving a malformed tree now prints nothing (Assert.Empty(chat.Snapshot())). Both pin the observable change at the surface a user sees.
SF-4 / doc-comment fix + SF-5 discriminator note	✔ GameEvents.cs:596 now cites the real ConfirmationTripleTests. The SF-5 split is cross-referenced at all three sites (:506-512 request, :536-539 done, :561-573 the enum) and states the decision FA4 inherits rather than leaving an unexplained inconsistency.

7.3 Carry-forward for FA2 (not a reopen)

CF-1 — lane D still names the deleted AllegianceTree in four more places, two of them forward-looking. The fix round applied blast MF-2's enumeration exactly; the enumeration itself stopped at four rows. A repo-wide sweep finds four further hits in docs/research/2026-08-11-fa-acdream-seams.md:

• :128 — the FA2 owner-graph diagram: "AllegianceOwner : RuntimeAllegianceState (new) └── owns the ported AcDream.Core.Allegiance.AllegianceTree".
• :214 — "AllegianceTree already lives in AcDream.Core.Allegiance — so the allegiance tree can be passed directly as a state parameter, exactly like friends".

Both are design guidance FA2 will follow, i.e. the same danger class as the :791 row that was corrected — an FA2 implementer reading either is told to own or pass a class that no longer exists. (:23 and :890 are the other two hits; both are historical "what exists today" inventory prose and are fine left alone, as is every surviving BuildFellowshipUpdate mention in lane B and in the plan's D3 — those correctly describe the pre-FA1 defect and must NOT be rewritten.)

This is the single-lens-enumeration failure mode the project's own feedback_blast_radius_single_lens note describes: the sweep leaked along the axis it did not traverse. One more dated addendum at each of :128 and :214 closes it; FA2 should not start before that.

7.4 Suite claim — consistent, and corroborated by direct measurement

The 13,158 passed / 4 skipped / 0 failed claim is arithmetically consistent and independently corroborated, though I did not run the full solution suite myself.

• Mechanical test-count delta. ed308087's test diff adds exactly 9 [Fact]/[Theory] attributes, removes 0, and adds 0 new InlineData rows. 13,149 + 9 = 13,158; 13,153 + 9 = 13,162 total. Both stated figures close.
• The ledger's own +9 attribution is correct: 2 (0x001F golden vectors) + 1 (D5 <<1 at 0x02C0) + 4 (MF-1 ×3 and SF-1's monarch test) + 2 (blast SF-1 live-surface pins) = 9, and that matches the files line by line.
• Direct measurement. The Release binaries in this worktree are stamped 00:47:19–00:47:20, after ed308087 (00:46:42), so --no-build is legitimate evidence here (unlike the stale Debug binaries noted in §6). AcDream.Core.Net.Tests now runs 886 passed / 0 failed / 0 skipped — exactly the blast doc's measured pre-fix anchor of 877 plus 9, and all 9 new tests live in that project. A narrower FA1-family filter (the six FA1 test classes plus ClientCommandResponsesTests) runs 92 passed / 0 failed.

That is as far as this lens can take it: every number in the ledger row now reconciles with every other, and the one project that changed measures exactly the claimed delta. Whether the other eight projects still total what the row says is the regression lens's call.