acdream/docs/research/2026-08-11-fa-acdream-seams.md

# Campaign FA — lane D: acdream seams for Fellowship & Allegiance

**Status:** RESEARCH ONLY (2026-08-11). Read-only audit of our own tree; no
retail decomp claims here (that is lanes A–C). Every claim is cited
`file:line` against the worktree
`.claude/worktrees/eloquent-hugle-42119e`.

**Purpose:** so the FA plan places new code correctly the first time.

---

## 0. Executive orientation — what already exists

FA is NOT greenfield. The tree already carries a partial, unwired
foundation laid in H.2 (2026-04-18) and extended incidentally by
Campaigns CH and OP:

| Already present | Where | Wired to production? |
|---|---|---|
| All 11 S→C event ids | `src/AcDream.Core.Net/Messages/GameEventType.cs:16,19,29,30,55,56,57,84,85,100,101,102` | **NO parsers, NO handlers** |
| Fellowship C→S builders (5) | `src/AcDream.Core.Net/Messages/SocialActions.cs:123-168` | **NO `WorldSession.Send*` wrapper, NO caller** |
| Allegiance C→S builders (2) | `src/AcDream.Core.Net/Messages/AllegianceRequests.cs:34-46` | **NO `WorldSession.Send*` wrapper, NO caller** |
| Client allegiance tree model | `src/AcDream.Core/Allegiance/AllegianceTree.cs:56-162` + XP passup `:172-183` | **NO writer; zero references outside its own file** |
| `RetailLogTextType.Allegiance 0x12` / `.Fellowship 0x13` | `src/AcDream.Core/Chat/RetailLogTextType.cs:44-45` | Colors already conformance-pinned (CH) |
| `RuntimeChatChannel.Fellowship/.Allegiance/.Vassals/.Patron/.Monarch/.CoVassals` | `src/AcDream.Runtime/GameRuntimeCommands.cs:63-90` | **YES** — outbound chat works today (`DirectGameRuntimeCommandAdapter.cs:1014-1062`) |
| `InputAction.ToggleAllegiancePanel` (F3) / `.ToggleFellowshipPanel` (F4) | `src/AcDream.UI.Abstractions/Input/InputAction.cs:103-106`, defaults `KeyBindings.cs:209-210`, retail ActionMap ids `RetailActionIdentityTable.cs:193-194` | **NO handler** — `RetailUiRuntime.HandleInputAction` (`RetailUiRuntime.cs:548-560`) has no case for either |
| 6 dimmed Grouping-group option rows | `src/AcDream.App/UI/Layout/CharacterOptionsPageController.cs:193-201` | Store-only (AD-78) |
| Retail mutual exclusion (MF-2) | `src/AcDream.Runtime/Gameplay/RuntimeCharacterState.cs:818-834` | **YES** — already live |
| Confirmation types 1 and 4 (allegiance/fellowship) placeholder | `src/AcDream.App/UI/GameplayConfirmationController.cs:36-40` | Generic dialog only; explicitly awaiting FA panels |

`AllegianceRequests.BuildSwear/BuildBreak` and every
`SocialActions.BuildFellowship*` have **zero production callers** — a
whole-tree grep returns only their own definitions and their tests. FA
must add the `WorldSession.Send*` wrappers (§3) before anything can reach
the wire.

Open issue ledger: `docs/ISSUES.md:12961` (**#L.4**, "Allegiance,
Fellowship, and World remain separate open panel features") and
`docs/ISSUES.md:524` (**#360**, the ~22 unported `@allegiance`/`@house`
subcommands).

---

## 1. Runtime ownership — where fellowship/allegiance state belongs

### 1.1 The J-pattern, as actually implemented

`GameRuntime` builds every gameplay owner in one ordered, fault-injectable
construction transaction (`src/AcDream.Runtime/GameRuntime.cs:156-320`),
exposes each as a public `*Owner` property (`:419-429`), and exposes a
**read-only typed borrowed view** per owner (`:463-470`). Convergence is
proved by a per-owner `CaptureOwnership()` rolled up through
`RuntimeGameplayOwnership.Capture`
(`src/AcDream.Runtime/Gameplay/RuntimeGameplayOwnership.cs:23-44`) →
`RuntimeSimulationOwnership.Capture`
(`src/AcDream.Runtime/RuntimeSimulationOwnership.cs:23-44`) →
`GameRuntime.CaptureOwnership` (`GameRuntime.cs:545-567`).

Every new J-owner therefore costs **eight** mechanical edits:

1. a `Runtime<X>State` class with `IDisposable`, `ResetSession()`,
   `CaptureOwnership()`;
2. a `Runtime<X>OwnershipSnapshot` record struct with an `IsConverged`
   expression (template: `RuntimeCharacterState.cs:9-51`);
3. construction + `construction.Own(...)` + a new
   `GameRuntimeConstructionPoint` fault point (`GameRuntime.cs:200-214` is
   the two-line template);
4. the `*Owner` property and its `IRuntime<X>View` projection
   (`GameRuntime.cs:419-429`, `:463-470`);
5. a field + a new `RuntimeGenerationResetStage` ordinal + a `Drain` case
   in `RuntimeGenerationReset`
   (`src/AcDream.Runtime/RuntimeGenerationReset.cs:21-44`, `:97-121`,
   `:236-349`);
6. inclusion in `RuntimeGameplayOwnershipSnapshot`
   (`RuntimeGameplayOwnership.cs:8-21`);
7. a shutdown-ledger step in `GameRuntime`'s ordered teardown
   (`GameRuntime.cs:703-752` — the numbered `switch` + `=>` pair must stay
   in lockstep);
8. a field on `RuntimeStateCheckpoint`
   (`src/AcDream.Runtime/GameRuntimeViews.cs:223-241`) and the matching
   `RuntimeTraceRecorder.AddCheckpoint` string
   (`src/AcDream.Runtime/GameRuntimeEvents.cs:154-224`) if the state is to
   appear in connected-gate artifacts.

### 1.2 Is `RuntimeCommunicationState` the natural home? — NO

`RuntimeCommunicationState`
(`src/AcDream.Runtime/Gameplay/RuntimeCommunicationState.cs:55-262`) owns
`ChatLog`, `SpewBoxState`, `ChatCommandTargetState`, `TurbineChatState`,
`FriendsState`, `SquelchState`, `ChatWindowState`, plus the
`IRuntimeCommunicationEventSource` chat stream (`:327-506`). Its J4.1
closeout describes its scope as exactly "chat transcript, reply/retell
command targets, negotiated Turbine rooms and context cookies, friends,
and squelch database"
(`docs/research/2026-07-26-slice-j4-1-communication-state.md:9-11`).

Three reasons FA state does **not** belong there:

- **Lifetime mismatch.** Friends/squelch are cleared at their own reset
  stages (`RuntimeGenerationReset.cs:277-282`) and are pure client-side
  lists. Fellowship membership is a server-authoritative *roster with live
  per-member vitals*, and allegiance is a *tree*. Folding them in makes
  `RuntimeCommunicationOwnershipSnapshot`
  (`RuntimeCommunicationState.cs:20-48`) a 20-field grab bag whose
  `IsConverged` no longer reads as one lifetime.
- **The J4 precedent is one owner per coupled graph, not per theme.** J4
  split inventory (J4.2), character (J4.3), and communication (J4.1) apart
  even though all three are "player state"; J4.3's stated rationale is that
  spellbook + local player "form one lifetime group because vital maxima
  read active enchantments from this exact spellbook"
  (`RuntimeCharacterState.cs:53-57`). Fellowship and allegiance have no
  such read-coupling to chat.
- **The two FA subsystems are themselves only loosely coupled.**
  Fellowship is a flat ≤9-member roster with a disband/quit/recruit
  lifecycle; allegiance is a persistent tree with monarch/patron/vassal
  edges and an XP-passup model that survives logout.

### 1.3 Recommended ownership shape

**Two sibling owners under `GameRuntime`, not one, and not a child of
Communication:**

```
GameRuntime
├── FellowshipOwner : RuntimeFellowshipState   (new)
│     └── borrows RuntimeEntityObjectLifetime (member guid → ClientObject)
└── AllegianceOwner : RuntimeAllegianceState   (new)
      └── owns the ported AcDream.Core.Allegiance.AllegianceTree
          ^^^ [FA1 fix-round addendum 2026-08-12, re-review CF-1:
          AllegianceTree was DELETED at 4281750b (lane C verdict —
          wrong passup transcription, wire-contradicting tree model).
          RuntimeAllegianceState owns the PARSED profile records from
          ClientCommandResponses.ReadAllegianceProfileBody instead —
          the flat vassal list + monarch/patron/self blocks, already
          assembled with retail's four rejection rules. Do not recreate
          a tree type.]
```

Rationale and precedent:

- **Separate owners** because the reset semantics differ: fellowship is
  session-scoped (a disconnect drops you from the fellowship server-side —
  clear it at reset, same class as `_inventory.ResetExternalContainer`,
  `RuntimeGenerationReset.cs:248-261`), whereas allegiance survives
  reconnect and is re-seeded from `PlayerDescription`/`AllegianceUpdate`
  (same class as `RuntimeCharacterOptionsState`'s `HasServerSeed` latch,
  `project_settings_options_digest.md` DO-NOT-RETRY row "Applying a
  pre-seed Reset/local snapshot over server truth").
  **[FA2 fix-round addendum, 2026-08-12
  (docs/research/2026-08-12-fa2-review-mechanism.md MUST-FIX 1): this
  citation was INVERTED. `RuntimeCharacterOptionsState`'s `HasServerSeed`
  latch does NOT survive a reset — `ResetSession`
  (`RuntimeCharacterState.cs:1007-1017`) explicitly zeroes the options AND
  clears `_hasServerSeed`, with its own doc comment naming the exact hazard
  this row then walked into: "a stale seed surviving a session boundary
  could let a flush ship the PRIOR character's words over the new one's."
  Retail itself clears allegiance at the same per-character-session
  boundary Fellowship already clears at
  (`ClientAllegianceSystem::OnEndCharacterSession @0x00569FA0` tail-calls
  `AllegianceProfile::Clear`, mirroring
  `ClientFellowshipSystem::OnEndCharacterSession @0x005690A0`). Corrected:
  allegiance is now ALSO a reset stage
  (`RuntimeGenerationResetStage.Allegiance`) with the identical
  clear-and-relatch shape as the cited precedent. The two owners remain
  separate classes because fellowship and allegiance are independent
  retail systems with independent wire families, not because their
  lifetimes differ — they no longer do.]**
- **Borrow, never copy, the entity table.** Fellowship member rows must
  read live names/vitals from `RuntimeEntityObjectLifetime`'s canonical
  `ClientObjectTable` the way `RuntimeInventoryState` does
  (`GameRuntime.cs:192-193`) — a second copy of member names is exactly the
  "two writable copies" divergence OP9 deleted
  (`project_settings_options_digest.md`, AP-196 row).
- **Typed borrowed views, not events, for the panels.**
  `IRuntimeSocialView` (`GameRuntimeGameplayViews.cs:105-110`) is the exact
  template: a `Snapshot` record struct plus `TryGet*` accessors, no
  collection allocation. Add `IRuntimeFellowshipView` /
  `IRuntimeAllegianceView` to `GameRuntimeGameplayViews.cs` and hang them
  off `IGameRuntimeView` (`GameRuntimeViews.cs:243-272`) so headless bots
  can assert roster state without touching presentation.
- **Generation-gated commands.** Add
  `IRuntimeFellowshipCommands` / `IRuntimeAllegianceCommands` to
  `GameRuntimeCommands.cs` alongside `IRuntimeSocialCommands` (`:291-300`),
  register them on `IGameRuntimeCommands` (`:302-325`), and add two
  `RuntimeCommandDomain` ordinals (`GameRuntimeEvents.cs:11-24` — currently
  `Magic = 10`, so `Fellowship = 11`, `Allegiance = 12`). Both host
  adapters must implement: `DirectGameRuntimeCommandAdapter`
  (`src/AcDream.Runtime/Session/DirectGameRuntimeCommandAdapter.cs:20-31`
  interface list, `:718-750` friend-command template) and
  `CurrentGameRuntimeCommandAdapter`
  (`src/AcDream.App/Runtime/CurrentGameRuntimeCommandAdapter.cs:690,703` —
  it publishes onto the App command bus instead of touching the session).
- **Ordered deltas only if a bot needs them.** The J-pattern's event hub
  (`GameRuntimeEventHub`, constructed at `GameRuntime.cs:304-307` from
  entity/communication/action owners) feeds `IRuntimeEventObserver`
  (`GameRuntimeEvents.cs:98-115`). A `OnFellowship(in
  RuntimeFellowshipDelta)` member is a **breaking change to every
  implementer** (5 bot policies in
  `src/AcDream.Headless/Policies/HeadlessBotPolicy.cs`, the trace recorder
  at `GameRuntimeEvents.cs:148-311`, App observers). Prefer **not** adding
  an observer member unless the bot gate (§6) genuinely needs push
  semantics; a `Snapshot.Revision` poll off the borrowed view is the
  cheaper contract and matches `IRuntimeSocialView`.

### 1.4 The one thing that *should* live in Communication

Fellowship/allegiance **system message text** (recruits, quits, logon
notices) is interface text, not fellowship state — it goes through
`RuntimeCommunicationState.AddText`
(`RuntimeCommunicationState.cs:210-239`). See §7.

---

## 2. Inbound wire routing — the pattern a new event family must follow

### 2.1 There is exactly ONE registration site, and it is in Runtime

`GameEventWiring.WireAll`
(`src/AcDream.Core.Net/GameEventWiring.cs:36-99`) is called from exactly
one place in `src/`: `LiveSessionEventRouter.Attach`
(`src/AcDream.Runtime/Session/LiveSessionEventRouter.cs:179-231`). A
whole-`src` grep for `WireAll` returns those two hits only. **This is the
K-slice unification: both hosts share the router.** So a new event family
is wired once and both hosts get it — but only if the *sink* is reachable
from both, which is why the sink must be a Runtime owner (§1) and not an
App object.

### 2.2 The mechanical shape

`GameEventWiring` is a static method taking one positional core
(`dispatcher, items, combat, spellbook, chat`) plus ~20 optional
delegate/state "holes" (`GameEventWiring.cs:41-99`). Core.Net **cannot
reference `AcDream.Runtime`** — the CH2 comment at
`GameEventWiring.cs:90-98` states this explicitly ("Core.Net cannot
reference AcDream.Runtime directly, so this is a delegate hole exactly
like every other Runtime-owned sink above"). Two legal shapes:

- **State object** (like `friends`, `squelch`, `itemMana`, `vendor`,
  `externalContainers`): the type lives in `AcDream.Core.*`, Runtime owns
  the instance, Core.Net writes into it. `FriendsState`/`SquelchState` live
  in `AcDream.Core.Social`; ~~`AllegianceTree` already lives in
  `AcDream.Core.Allegiance` — so the allegiance tree can be passed
  directly as a state parameter, exactly like `friends`~~ [FA1 fix-round
  addendum 2026-08-12, re-review CF-1: `AllegianceTree` was DELETED at
  `4281750b`. The pattern itself stands — the PARSED allegiance profile
  records (from `ReadAllegianceProfileBody`, in `AcDream.Core.Net`) are
  what gets passed/held; FA2 defines the owned snapshot type in
  `AcDream.Core.*` if a Core-side holder is needed, or holds the parsed
  records directly in the Runtime owner].
- **Delegate hole** (like `onCharacterOptions`, `onInterfaceText`,
  `onUseDone`): a `Action<...>` the router closes over.

Registration itself: `registrar.Register(GameEventType.X, e => {...})`
against the owned registrar (`GameEventWiring.cs:923-943`), which wraps
every handler in the `accepting` gate so a retiring generation cannot
receive. Do not register outside `WireAll` — the `RegistrationBuildScope`
(`:945-961`) guarantees all-or-nothing ownership.

### 2.3 The 11 events FA must register

From `GameEventType.cs`:

| Id | Name | Line |
|---|---|---|
| `0x0003` | `AllegianceUpdateAborted` | `:16` |
| `0x0020` | `AllegianceUpdate` | `:19` |
| `0x00A3` | `FellowshipQuit` | `:29` |
| `0x00A4` | `FellowshipDismiss` | `:30` |
| `0x01C8` | `AllegianceUpdateDone` | `:55` |
| `0x01C9` | `FellowshipFellowUpdateDone` | `:56` |
| `0x01CA` | `FellowshipFellowStatsDone` | `:57` |
| `0x027A` | `AllegianceLoginNotification` | `:84` |
| `0x027C` | `AllegianceInfoResponse` | `:85` — **already registered** (`GameEventWiring.cs:192-198`, TS-70 fix) |
| `0x02BE` | `FellowshipFullUpdate` | `:100` |
| `0x02BF` | `FellowshipDisband` | `:101` |
| `0x02C0` | `FellowshipUpdateFellow` | `:102` |

Note `0x027C` is already consumed for `@allegiance info` chat output
(`GameEventWiring.cs:192-198` → `ClientCommandResponses.ParseAllegianceInfoResponse`).
FA must **not** register a second handler for it; either extend the
existing lambda or add a second `registrar.Register` for the same type
(the dispatcher supports multiple owned handlers per type — see
`OwnedGameEventRegistrar.Register`, `:929-940`) and accept that both fire.
Decide this in the plan, explicitly.

**[FA2 fix-round addendum, 2026-08-12
(docs/research/2026-08-12-fa2-review-blast.md SHOULD-FIX 1): the
parenthetical above is WRONG and was disproved during FA2 implementation.
`GameEventDispatcher.Dispatch`
(`src/AcDream.Core.Net/Messages/GameEventDispatcher.cs:95-117`) does a
single `_handlers.TryGetValue(...)` and invokes the ONE stored
`RegistrationNode`; `OwnedGameEventRegistrar.Register` REPLACES the prior
registration for that `GameEventType`, it does not add a second co-owned
handler. A second `registrar.Register(GameEventType.AllegianceInfoResponse,
...)` call would have silently killed the already-live `@allegiance info`
chat-text output the instant a caller supplied an allegiance-owner
callback. FA2 folded both behaviors into the ONE existing registration
instead (`GameEventWiring.cs`'s `AllegianceInfoResponse` handler) — see
that method's own code comment for the corrected claim. This was also the
right call independent of the correction: FA2's fix round (MUST-FIX 2)
subsequently found that `0x027C` should not feed a Runtime callback at
all, since retail's own handler for it is print-only over a stack-local
profile — so the "second handler" question this section poses is now moot
either way.]**

`0x01C9 FellowshipFellowUpdateDone` and `0x01CA FellowshipFellowStatsDone`
from the table above are **[FA2 fix-round addendum, 2026-08-12
(docs/research/2026-08-12-fa2-review-blast.md SHOULD-FIX 2): correctly
left unregistered by FA2.** FA1 established that both COMDAT-fold onto the
identical no-op body in the Sept-2013 client and are parse-and-ignore only
(`src/AcDream.Core.Net/Messages/GameEvents.cs:779-803`) — there is nothing
for a Runtime owner to consume. This is the disposition for the two rows
this section's own title ("The 11 events FA must register") implied FA
owed a registration for; FA2 registered the other 9 plus the `0x027C`
fold, 10 total.]**

### 2.4 Bindings-record plumbing (both hosts)

`LiveSessionEventRouter`'s five binding records are the host-facing
contract (`LiveSessionEventRouter.cs:15-82`). FA adds either a field to
`LiveSocialSessionBindings` (`:72-82`) or a **new**
`LiveFellowshipSessionBindings`/`LiveAllegianceSessionBindings` record.
Prefer extending `LiveSocialSessionBindings` with **trailing optional
parameters** — the established compatibility convention, stated at
`:42-44` ("Trailing/optional so every existing positional caller
(Headless) compiles unchanged").

Both construction sites must be updated (**blast-radius rule: the no-window
host is a first-class consumer**):

- Graphical: `src/AcDream.App/Net/LiveSessionRuntimeFactory.cs:248-261`
  (`new LiveSocialSessionBindings(_domain.Communication.Chat, ...)`).
- Headless: `src/AcDream.Headless/Hosting/HeadlessSessionHost.cs:780-785`
  (`new LiveSocialSessionBindings(Runtime.CommunicationOwner.Chat, ...)`).

Each host then wraps the router: `GraphicalSessionEventRoute`
(`src/AcDream.App/Net/GraphicalSessionEventRoute.cs`) and
`HeadlessSessionEventRoute`
(`src/AcDream.Headless/Hosting/HeadlessSessionEventRoute.cs:14-53`). Both
delegate `Attach`/`Dispose` to the shared router, so **no FA change is
needed in the wrappers** provided the sink is Runtime-owned.

### 2.5 Parsers

New parsers go in `src/AcDream.Core.Net/Messages/GameEvents.cs` (609
lines, static `Parse*` returning nullable structs — the file currently has
zero fellowship parsers; the only `Allegiance` token is
`AllegianceMonarchId` at `:589`, a `PlayerDescription` field). Follow the
`ParseChannelBroadcast` / `ParseTell` shape: `ReadOnlySpan<byte>` in,
`Nullable<struct>` out, `null` on malformed.

---

## 3. Outbound actions — the C→S builder pattern

### 3.1 `SocialActions` IS the right file for fellowship

`src/AcDream.Core.Net/Messages/SocialActions.cs` already declares the five
fellowship opcodes as constants (`:36-41`) and ships all five builders
(`:123-168`). It also — awkwardly — hosts `CharacterOptionId`
(`:362-417`) and the `0x0005`/`0x01A1` option builders. Keep fellowship
here; do **not** create a `FellowshipActions.cs` that splits the family.

Allegiance already has its own file
(`src/AcDream.Core.Net/Messages/AllegianceRequests.cs:27-56`, Swear
`0x001D` / Break `0x001E`). Extend that file for the remaining allegiance
GameActions (#360's boot/ban/officer/title/motd/name/lock/house set) rather
than moving them into `SocialActions`.

### 3.2 The missing link: `WorldSession.Send*` wrappers

Every outbound family reaches the wire through a
`WorldSession.Send<Verb>()` method that allocates the sequence and calls
`SendGameAction` — e.g.
`WorldSession.SendSetSingleCharacterOption`
(`src/AcDream.Core.Net/WorldSession.cs:2202-2206`) and
`SendAllegianceInfoRequest` (`:2312-2316`). **No such wrapper exists for
any fellowship or swear/break builder.** FA must add:

```
SendFellowshipCreate / Quit / Dismiss / Recruit / Update
SendAllegianceSwear / SendAllegianceBreak
```

then reach them from `DirectGameRuntimeCommandAdapter` (Runtime, direct)
and via a `*RuntimeCmd` record + `LiveSessionCommandRouter` registration
for the App bus path
(`src/AcDream.App/Net/LiveSessionCommandRouter.cs:74-81` declares the
records, `:173-186` registers the handlers).

### 3.3 Golden-vector test conventions

`tests/AcDream.Core.Net.Tests/Messages/` is the home
(`SocialActionsTests.cs`, `AllegianceRequestsTests.cs` already exist).
Two tiers, both used:

- **Field-probe tests** — read individual offsets back
  (`SocialActionsTests.cs:53-104` covers all five fellowship builders;
  `AllegianceRequestsTests.cs:10-34` covers swear/break). Cheap, and what
  the existing FA builders have.
- **Hand-computed golden byte vector** — the OP1 convention, and the
  stronger one. `SocialActionsTests.cs:136-142` states the rule verbatim:
  *"The golden vector below is HAND-COMPUTED, field by field, from that
  layout — not generated by calling the builder under test. The CH3 builder
  (deleted 2026-08-09) died of ten green tests pinning a wrong shape."*
  Example at `:144-175`. **Any FA builder whose layout lane A/B/C had to
  derive (rather than copy from an existing green test) must get a
  hand-computed golden vector.** `AceWireWriter.cs` in the same directory
  is the test-only ACE-mirror writer for inbound goldens.

`git`-visible caution: `BuildFellowshipCreate`'s padding math
(`SocialActions.cs:128-137`) computes `pad` but never uses it in the
`body` length beyond `new byte[12 + name.Length + boolBlock + pad]` — the
existing test (`SocialActionsTests.cs:53-68`) asserts bool offsets 20/21
for a 4-char name, i.e. it pins the current shape but **not against a
retail/ACE reference**. Lane A/B should confirm the trailing-pad rule
before FA relies on it.

---

## 4. The AD-78-dimmed rows that gain consumers

### 4.1 Exact inventory — the six Grouping-group rows

All six live in `CharacterOptionsPageController.Groups[2]`
(`src/AcDream.App/UI/Layout/CharacterOptionsPageController.cs:193-201`),
header `ID_CharacterOption_Grouping_Section`, and all six are `StoreOnly`:

| `CharacterOptionId` | Value | Word/mask | AutoSave | ClientDefault | Controller line | Table line |
|---|---|---|---|---|---|---|
| `IgnoreAllegianceRequests` | `0x01` | Options1 `0x00000004` | yes | false | `:195` | `CharacterOptionTable.cs:112` |
| `IgnoreFellowshipRequests` | `0x02` | Options1 `0x00000008` | yes | **true** | `:196` | `:113` |
| `DisplayAllegianceLogonNotifications` | `0x18` | Options1 `0x08000000` | no | false | `:197` | `:135` |
| `FellowshipShareXP` | `0x0F` | Options1 `0x00040000` | yes | **true** | `:198` | `:126` |
| `FellowshipShareLoot` | `0x11` | Options1 `0x00100000` | yes | false | `:199` | `:128` |
| `FellowshipAutoAcceptRequests` | `0x12` | Options1 `0x20000000` | yes | false | `:200` | `:129` |

A seventh row is FA-adjacent but Chat-group:
`ListenToAllegianceChat` (`0x1B`, Options1 `0x40000000`) at
`CharacterOptionsPageController.cs:229` — **already `Live`**, consumed by
`TurbineChatMembershipGate.cs:107-110`. Do not touch it.

### 4.2 The tests that pin the dimmed list — un-dim goes through these

`tests/AcDream.App.Tests/UI/Layout/CharacterOptionsPageControllerTests.cs`:

- `ExpectedStoreOnlyIds` literal set — the 35-id hand-transcribed
  authority (`:710-753`). The six FA ids are at `:728-733` under the
  comment `// Group 3 (Grouping) — all 6`.
- **`StoreOnlyRows_MatchTheDerivationTableExactly`** (`:755-766`) —
  asserts set equality with `Groups`, plus `Assert.Equal(35, ...)` and
  `Assert.Equal(15, 50 - ...)`. **Un-dimming N rows requires editing three
  numbers here**: remove from the literal set, and change `35`→`35-N` and
  `15`→`15+N`.
- **`Bind_AppliesDimmedCaptionColor_ForStoreOnlyRows_AndWhiteForLiveRows`**
  (`:768-819`) — builds the real fixture tree and compares each checkbox's
  `LabelColor` against `UiRenderContext.StoreOnlyCaptionColor` vs
  `Vector4.One`, row-index-aligned. Derived from `Groups`, so it follows
  automatically once `Groups` flips.

The class doc states the contract explicitly at `:700-709`: *"Wiring a
future consumer for any of these means removing it from this literal set
AND flipping its `Groups` table entry from `StoreOnly` to `Live`
consciously — leaving either one stale fails this test."*

The dim mechanism itself is `CharacterOptionsPageController.cs:418-423`
(`checkbox.LabelColor = spec.StoreOnly ? UiRenderContext.StoreOnlyCaptionColor
: Vector4.One`). Rows stay fully interactive either way — only the caption
dims.

### 4.3 Which rows *should* un-dim, and which should not

The plan must decide per-row, but the code evidence says:

- `IgnoreFellowshipRequests` / `FellowshipAutoAcceptRequests` — **already
  have a genuine coded client-side consumer**: retail's `OnChanged` mutual
  exclusion (MF-2), ported at
  `src/AcDream.Runtime/Gameplay/RuntimeCharacterState.cs:818-834` with the
  full rationale in the `<remarks>` at `:790-805`. The OP4 author flagged
  this as a known ambiguity and deliberately left them dimmed
  (`CharacterOptionsPageController.cs:147-154`: *"have a genuine coded
  mutual-exclusion side effect … kept dimmed per the doc's explicit Group A
  listing … a future un-dim is a one-line judgment call, not a
  re-investigation."*). **FA gives them a real second consumer** (the
  incoming-fellowship-request path), so these two are the clearest un-dim
  candidates.
- `DisplayAllegianceLogonNotifications` — un-dims only if FA implements the
  `AllegianceLoginNotification 0x027A` handler AND gates its chat output on
  the bit. That gate is the consumer.
- `FellowshipShareXP` / `FellowshipShareLoot` — these are **server-side**
  policy (ACE decides the split). They un-dim only if FA reads them to
  drive the create-fellowship dialog's initial checkbox state
  (~~`BuildFellowshipCreate(seq, name, openness, shareXp)`,
  `SocialActions.cs:123-138`~~ **[FA1 fix-round addendum, 2026-08-12: FA1
  repaired this builder — there is no "openness" field on
  `FellowshipCreateOpcode`'s wire (the prior 4-arg builder invented one and
  silently sent it as the low byte of shareXP, which ACE would read as an
  INVERTED shareXP value). The current signature is
  `BuildFellowshipCreate(seq, fellowshipName, shareXp)`,
  `SocialActions.cs:144-155`.]**, takes `shareXp` as a parameter — that IS a
  client-side read). `FellowshipShareXP` is additionally tagged Group D
  (deferred) in the derivation table (`:137`).
- `IgnoreAllegianceRequests` — un-dims if FA gates the incoming-swear
  confirmation on it.

**MF-2 is binding on any un-dim.** `HeadlessConfigurationLoader.cs:252-274`
already rejects a bot config declaring both `IgnoreFellowshipRequests` and
`FellowshipAutoAcceptRequests` true, because retail's recursive clear makes
that unsatisfiable. Any FA UI that surfaces both toggles inherits the same
constraint — the panel must reflect the auto-clear, since `TrySetOption`
performs it locally before the send (`RuntimeCharacterState.cs:812-841`).

---

## 5. Panel mounting, dialogs, strings

### 5.1 Cataloging a new `gmPanelUI` panel

`src/AcDream.App/UI/RetailPanelCatalog.cs` holds the DAT property
`0x10000029` panel-id constants (`:10-18`) plus two tables: `Mounted`
(`:31-43`) and `Toolbar` (`:45-51`). FA adds `Allegiance` and `Fellowship`
constants **byte-verified from the authored toolbar/panel property**, the
way OP3 verified `Options = 10u` (`:20-29` documents that exact method:
read property `0x10000029` off the toolbar button in the committed fixture
AND cross-check the decompiled slot-key table). Do not guess the ids.

Window names go in `src/AcDream.App/UI/WindowNames.cs:5-32` (one `const
string` each) — the file's own doc says it exists "so the mount, the window
registry, and the toggle keybind all agree on one literal."

### 5.2 Mount method template

`RetailUiRuntime.MountCharacter`
(`src/AcDream.App/UI/RetailUiRuntime.cs:2663-2706`) is the cleanest
template — 44 lines, five steps:

1. `Import(0x2100002Eu)` → `ImportedLayout?`, log-and-return on null
   (`:2665-2670`);
2. build/subscribe the data provider (`:2671-2674`);
3. `<X>Controller.Bind(layout, ...)` (`:2675-2682`);
4. `RetailWindowFrame.Mount(Host.Root, layout.Root, resolveSprite, new
   RetailWindowFrame.Options { WindowName = ..., Chrome = NineSlice, ...,
   Visible = false, ... })` → `RetailWindowHandle` (`:2683-2700`);
5. `_panelUi.RegisterMainPanel(RetailPanelCatalog.X, WindowNames.X,
   handle)` (`:2701-2704`).

Then add the `Mount<X>()` call to `Initialize()`
(`RetailUiRuntime.cs:385-413` — the ordered list; note `MountDialogFactory`
at `:404` runs **before** `MountCharacter` at `:405`, and
`MountCharacter`'s own `HandleCharacterRaise` throws if that ordering is
violated, `:2720-2723`). Any FA panel that raises a confirmation must be
mounted after `MountDialogFactory`.

`RegisterMainPanel` (`src/AcDream.App/UI/Layout/RetailPanelUiController.cs:47-65`)
enforces name==handle.Name and shares one parent geometry across all
registered main panels — that is retail's `gmPanelUI` single-active-child
behavior, so FA panels get "opening Fellowship closes Allegiance" for free.

`RetailWindowManager.Register`
(`src/AcDream.App/UI/RetailWindowManager.cs:57-105`) is called by
`RetailWindowFrame.Mount` — FA does not call it directly. It requires the
outer frame be a **direct `UiRoot` child** (`:70-72`) and fires
`WindowRegistered` (`:44`) so the opacity controller picks the window up
automatically.

Bindings: add a `FellowshipRuntimeBindings` / `AllegianceRuntimeBindings`
group to the `RetailUiRuntimeBindings` record
(`RetailUiRuntime.cs:300-325`) — one record per subsystem is the
established grouping.

Keybinds: wire `InputAction.ToggleAllegiancePanel` /
`.ToggleFellowshipPanel` into `RetailUiRuntime.HandleInputAction`
(`:548-560` — the `ToggleSpellbookPanel` case at `:552-556` is the
one-liner template). The enum members, retail ActionMap ids, and F3/F4
defaults already exist (§0) — **only the handler is missing.**

Persistence: if the panel should keep its own visibility across sessions,
it must NOT be listed in `stateManagedVisibilityWindows`
(`RetailUiRuntime.cs:422-428`).

### 5.3 The confirmation seam — recruit / swear

`RetailDialogFactory`
(`src/AcDream.App/UI/Layout/RetailDialogFactory.cs:8-38`) is the port of
retail's `DialogFactory @0x004773C0`. Two entry points:

- `MakeConfirmation(message, callback, queueKey, priority)`
  (`:125-136`) — the simple seam.
- `MakeDialog(RetailDialogData, callback)` (`:74-123`) — full control over
  queue key, priority preemption, and `RetailDialogProperty` flags.

**Server-driven** confirmations (which is what an incoming
recruit/swear request is) already have a semantic owner:
`GameplayConfirmationController`
(`src/AcDream.App/UI/GameplayConfirmationController.cs:12-102`). Its
`HandleRequest` comment names FA explicitly at `:36-40`:

> *"Types 1 and 4 have allegiance/fellowship semantic owners but use the
> same response tuple, so this controller retains that tuple until those
> panels exist."*

So the FA plan should decide whether types 1/4 stay on the generic
controller (retaining the `(serverType, serverContext)` tuple, response
sent at `:87-101`) or gain their own owners. Note the single-slot guard at
`:44-47`: a second gameplay confirmation is **refused** while one is open —
mirror retail. Also mirror the DO-NOT-RETRY row from
`project_chat_digest.md`: `OpenNextDialog` must return early when the queue
key is already occupied (`RetailDialogFactory.cs:323-334`), because a
two-stage confirmation (the FA recruit-then-confirm flow is a candidate)
can synchronously reopen under the same key.

### 5.4 String resolution

`DatStringResolver`
(`src/AcDream.App/UI/Layout/DatStringResolver.cs:16-83`). Two rules:

- `ComputeHash(string)` (`:68-82`) is the exact retail ELF-style hash from
  `compute_str_hash @0x00413110`. Labels are resolved as
  `resolveString(tableId, ComputeHash("ID_..."))` — never hard-coded
  English. Template: `CharacterOptionsPageController.cs:409-416`, which on
  a failed lookup logs and leaves the caption **null**, explicitly "rather
  than invented English."
- Table ids are family-specific. `0x23000003` is the options family
  (`CharacterOptionsPageController.cs:84`); `0x2300000D` is the chat
  text-filter family; `0x23000004` is keyboard refusal
  (`project_settings_options_digest.md` DO-NOT-RETRY row). **FA must
  dat-verify which table holds `ID_Fellowship_*` / `ID_Allegiance_*` before
  assuming `0x23000003`.**
- Resolution is **per-`Build`, not per-import**: the resolver is passed
  into `LayoutImporter.Build` as its fifth argument
  (`RetailUiRuntime.cs:2041-2046`) AND separately into each page/row
  controller (`:2100`). Omitting it from either produces silent blanks —
  that was half of #375.

### 5.5 DO-NOT-RETRY rows transcribed from `project_settings_options_digest.md`

These are the mount-a-new-panel traps Campaign OP paid for. All apply
verbatim to an FA panel:

| Trap | Truth |
|---|---|
| Lazily creating a fill-anchored child at 0×0 | **#372.** `ComputeAnchoredRect` captures the degenerate baseline **permanently** → whole-page blank. Seed the viewport size to the parent extent at creation (`UiTemplateListBox`). *Fixture conformance tests stayed GREEN through this* — only mount+activate+switch+assert-drawn tests catch the class. |
| Assuming an imported tab host is active | **#375 residual.** A tab control must be explicitly activated (`controller.ActivateTabs()`), and the FA panel's own tab control if it has one. Commit `a8ce010d`. |
| Parked template prototypes / missing string resolver | **#375.** A template list whose prototypes were never parented, plus a `Build` call missing its string resolver, both render as blank rows. Commit `8bd7e3b8`. |
| Flat `layout.FindElement` for shared element ids | Apply/Reset/Defaults share element ids **across pages**. Always per-page scoped `FindDescendant`, never a flat layout lookup. (`CharacterOptionsPageControllerTests.cs:389-394` documents the collision.) |
| Open popups losing pointer routing | **#374.** An open dropdown/popup gets **first claim** on pointer routing in `UiRoot`. Commit `355c86a6`. |
| Rows straddling the viewport edge vanishing | **#371.** A viewport must `ClipsChildren` + intersection-cull, not whole-row-cull. Commit `a59e077a`. |
| Trusting a BN literal-0 operand for a string id / global | Bit Campaign OP **four times**. Byte-verify from the PDB-paired `acclient.exe` (`check_exe_pdb.py` MATCH) before believing a 0. |
| Re-adding a client copy of a server bit | AP-196 is closed. Server bits live ONLY in `RuntimeCharacterOptionsState`; client-only prefs in the Config-tab store. |

---

## 6. Headless bot seam for counterpart characters

### 6.1 What K2 gives you today

`IHeadlessBotPolicy`
(`src/AcDream.Headless/Policies/HeadlessBotPolicy.cs:7-12`):

```csharp
internal interface IHeadlessBotPolicy : IRuntimeEventObserver, IDisposable
{
    bool IsComplete { get; }
    void Tick(IGameRuntimeView view, IGameRuntimeCommands commands);
}
```

Policies are string-selected by config id in
`HeadlessBotPolicyFactory.Create` (`:16-27`); five exist today: `idle`,
`lifecycle-smoke`, `observer-movement`, `portal-route-smoke`,
`jump-probe`. `LifecycleSmokeHeadlessBotPolicy.Tick` (`:92-142`) is the
canonical stage-machine template — every command call is
generation-gated (`commands.Chat.Execute(view.Generation, ...)`, `:103`)
and its result checked via `Require(...)`.

Config shape: `HeadlessSessionDescriptor`
(`src/AcDream.Headless/Configuration/HeadlessConfiguration.cs:38-75`) —
`id`, `endpoint`, `account`, `character`, `policy`, `credential`, optional
`characterOptions`. Note the MF-1 comment at `:32-37`: it is a **record**
so `with` expressions in the direct-CLI path cannot silently drop a
property. Multiple sessions in one process is already the shape
(`Sessions` list, `:13`) and K3/K4 gated 1/5/10/30-session isolation.

Declared-option validation: `AllowedCharacterOptions`
(`HeadlessConfigurationLoader.cs:27-57`) — **all six FA option ids are
already tier-1 allow-listed** (`:30,31,34,36,37,38`), plus
`ListenToAllegianceChat` (`:46`). The MF-2 contradiction check is at
`:252-274`.

Option seeding engine: `HeadlessCharacterOptionsSeeder`
(`src/AcDream.Headless/Hosting/HeadlessCharacterOptionsSeeder.cs:58-136`)
— diff-and-send through the SAME `IRuntimeCharacterCommands` seam, gated
on a two-precondition latch (`LoginComplete` sent AND `HasServerSeed`).

Existing bot-vs-ACE gate recipe: `docs/research/2026-08-11-campaign-op-test-script.md:766-895`
(§OP7). Its structure — declare a config, run `acdream-headless run
--config X.json`, inspect ACE-side persisted state, then re-run for
idempotence — is exactly reusable for FA.

### 6.2 What a bot-recruits-bot fellowship gate needs added

**Config / infrastructure:**

1. **A second ACE account.** The OP7 recipe uses one session
   (`testaccount` / `+Acdream`). A fellowship gate needs two logged-in
   characters simultaneously. K3 already gated multi-session isolation, and
   `HeadlessConfiguration.Sessions` is a list — but the **credential**
   model is per-session (`HeadlessCredentialReference`, `:107-114`), so two
   distinct env-var references (e.g. `FA_BOT_A_PASSWORD`,
   `FA_BOT_B_PASSWORD`) suffice **if** ACE has a second account with a
   second character. *This is the one genuinely external prerequisite —
   flag it for the user.* CLAUDE.md documents only `testaccount` /
   `+Acdream`.
2. **The two bots must be co-located.** Recruit requires the target be
   within range and selectable. Either both characters start at the same
   spawn, or the policy drives one to the other (the
   `ObserverMovementHeadlessBotPolicy` / `PortalRouteSmokeHeadlessBotPolicy`
   movement machinery already exists, `HeadlessBotPolicy.cs:204-306`,
   `:353-593`).
3. **A new policy id**, e.g. `fellowship-smoke`, registered in
   `HeadlessBotPolicyFactory.Create` (`:16-27`), with a role discriminator
   (leader vs recruit). The policy interface has no per-session parameter
   today beyond the id string — either encode the role in the id
   (`fellowship-smoke-leader` / `fellowship-smoke-member`) or extend
   `HeadlessBotPolicyDescriptor` (`HeadlessConfiguration.cs:93-97`, which
   currently carries only `Id`).

**Runtime commands the policy needs (new, §1.3/§3.2):**

| Command | Underlying builder |
|---|---|
| `commands.Fellowship.Create(gen, name, open, shareXp)` | `SocialActions.BuildFellowshipCreate` **[FA1 fix-round addendum, 2026-08-12: the builder is now 3-arg — `BuildFellowshipCreate(seq, fellowshipName, shareXp)` (`SocialActions.cs:144-155`). There is no wire "openness" field; drop `open` from this command's own signature too.]** |
| `commands.Fellowship.Recruit(gen, targetGuid)` | `BuildFellowshipRecruit` |
| `commands.Fellowship.Quit(gen, disband)` | `BuildFellowshipQuit` |
| `commands.Fellowship.Dismiss(gen, targetGuid)` | `BuildFellowshipDismiss` |
| `commands.Fellowship.SetOpen(gen, open)` | ~~`BuildFellowshipUpdate`~~ **[FA1 fix-round addendum, 2026-08-12: `BuildFellowshipUpdate` no longer exists. Its renamed successor `BuildFellowshipUpdateRequest` (`0x00A6`) is PANEL VISIBILITY, not openness — wiring `SetOpen` to it would re-introduce the exact semantic bug FA1 fixed. The real openness action is `BuildFellowshipChangeOpenness` (`0x0291`, `SocialActions.cs:222-230`).]** |
| `commands.Allegiance.Swear(gen, patronGuid)` | `AllegianceRequests.BuildSwear` |
| `commands.Allegiance.Break(gen, targetGuid)` | `BuildBreak` |

Plus target acquisition: the recruit target is another player's server
guid. `RuntimeHostileTargetQuery.FindClosest`
(`src/AcDream.Runtime/Gameplay/RuntimeHostileTargetQuery.cs`, used at
`HeadlessGameplayOperations.cs:143`) finds hostiles only — FA needs a
**friendly/player** nearest-object query, or the policy reads
`view.InventoryState`/entity deltas for a known character name. The bot
already receives `OnEntity` deltas
(`GameRuntimeEvents.cs:104`), so name-matching off `RuntimeEntitySnapshot`
is the low-friction route.

**Views the policy needs to assert on:**

- `view.Fellowship.Snapshot` — at minimum `{ Revision, IsInFellowship,
  Name, MemberCount, LeaderGuid, IsOpen }`, plus
  `TryGetMember(guid, out RuntimeFellowMemberSnapshot)`. Modeled on
  `IRuntimeSocialView` (`GameRuntimeGameplayViews.cs:105-110`).
- `view.Allegiance.Snapshot` — `{ Revision, MonarchGuid, PatronGuid,
  VassalCount, Rank }`, plus `TryGetNode`.

**Gate assertions (what "passed" means):**

1. Bot A creates a fellowship → A's `Fellowship.Snapshot.IsInFellowship`
   true, `MemberCount == 1`.
2. A recruits B → B's own snapshot flips (proving the `0x02BE`
   `FellowshipFullUpdate` inbound path reached B's Runtime owner, not just
   A's local echo). **This is the assertion that only a two-bot gate can
   make.**
3. `FellowshipAutoAcceptRequests` declared true on B via
   `characterOptions` → recruit succeeds without a confirmation; declared
   false → ACE sends `CharacterConfirmationRequest` type 4 and the bot must
   answer it (needs a bot-visible confirmation command, or the policy
   declares auto-accept to avoid it in v1 — **recommend v1 declares
   auto-accept**).
4. `IgnoreFellowshipRequests` true on B → recruit refused; asserts the
   server honors the bit.
5. B quits → A's `MemberCount` drops (proving `0x00A3`/`0x02C0` inbound).
6. A disbands → both snapshots clear (proving `0x02BF`).
7. Graceful SIGINT → both Runtime roots converge, FA owners' ownership
   snapshots `IsConverged` (the K4 terminal-ownership check,
   `src/AcDream.Headless/Hosting/HeadlessStaticStateAudit.cs`).

Allegiance's swear/break is harder to gate: ACE enforces rank/vassal-cap
rules and swearing is semi-permanent on a shared test character. Recommend
the FA plan gate **fellowship with two bots** and gate **allegiance
manually via the graphical client** against a throwaway pair, rather than
burning `+Acdream`'s allegiance state.

---

## 7. Chat / interface-text seam

### 7.1 The chokepoint

`RuntimeCommunicationState.AddText(string text, RetailLogTextType type,
uint windowId = 0)`
(`src/AcDream.Runtime/Gameplay/RuntimeCommunicationState.cs:210-239`) is
the one seam, the port of `ClientSystem::AddTextToScroll @0x00563C50`.
Behavior: `Trim()` both ends (`:227`, and the comment at `:214-226`
explains why there is deliberately **no** empty-string guard);
`ClientLocal 0x1A` → SpewBox only (`:229-233`); everything else →
`Chat.OnSystemMessage(text, (uint)type)` (`:238`).

Reached from Core.Net through the `onInterfaceText` delegate hole
(`GameEventWiring.cs:90-98`), supplied by
`LiveSocialSessionBindings.AddText`
(`LiveSessionEventRouter.cs:77-82`) — bound in **both** hosts
(`LiveSessionRuntimeFactory.cs:261`, `HeadlessSessionHost.cs:785`).

### 7.2 Which `RetailLogTextType` FA messages use

`src/AcDream.Core/Chat/RetailLogTextType.cs`:

- `Allegiance = 0x12` (`:44`)
- `Fellowship = 0x13` (`:45`)

Both already have retail-exact RGBA in `RetailChatColorTable`
(`AcDream.UI.Abstractions`), conformance-pinned to
`ChatInterface::BuildChatColorLookupTable @0x4f31c0`
(`project_chat_digest.md`, "Current truth"). **No color work needed —
just pass the right type.**

Rules carried from the chat digest:

- **Do not add chat-color configurability.** Retail hard-codes every
  `LogTextType`; only per-window type *filters* are user-settable.
- **`ClientLocal 0x1A` is SpewBox-only** and must never reach the
  scrolling chat window. Local FA refusals ("You are ignoring fellowship
  requests.") are the `0x1A` class; server-sent roster notices are
  `0x13`/`0x12`.
- **Refusal text comes from `WeenieErrorMessages`** (344 rows, binary-swept
  — `src/AcDream.Core/Chat/WeenieErrorMessages.cs`), not from invented
  English. FA refusals arriving as `WeenieError`/`WeenieErrorWithString`
  already route correctly through the existing `GameEventWiring`
  registration; FA only needs to confirm the specific ids
  (`YouAreNotInAFellowship`, `FellowshipIsFull`, etc.) exist in the table.
- Register row **AP-183 / #363** notes ~10 sites typed `0x00` where retail
  types `0x1A` — do not add more.

### 7.3 Allegiance logon notifications

`AllegianceLoginNotification 0x027A` is the one FA message whose *display*
is gated by a character option:
`DisplayAllegianceLogonNotifications` (`0x18`, Options1 `0x08000000`,
non-auto-save — `CharacterOptionTable.cs:135`). The gate must read the
Runtime option bit, exactly like `TurbineChatMembershipGate.cs:105-136`
does for the six `ListenTo*Chat` bits. **That gate is the consumer that
un-dims the row** (§4.3).

Note the chat-digest distinction: `Hear*Chat` bits are channel
*membership* (retail refuses to even send). `DisplayAllegianceLogonNotifications`
is different — it is a genuine *receive-side display* filter, so the
inbound handler must swallow the notice locally when the bit is off. Lane
A/B should confirm this against retail rather than inferring it from ACE.

---

## 8. Seam map (summary table)

| Subsystem | Where new code goes | Pattern to follow | Precedent citation |
|---|---|---|---|
| Fellowship state owner | `src/AcDream.Runtime/Gameplay/RuntimeFellowshipState.cs` (new) | J4 owner: `IDisposable` + `ResetSession()` + `CaptureOwnership()`; borrow entity table | `RuntimeInventoryState` ctor `GameRuntime.cs:192-193`; snapshot shape `RuntimeCharacterState.cs:9-51` |
| Allegiance state owner | `src/AcDream.Runtime/Gameplay/RuntimeAllegianceState.cs` (new), ~~wrapping existing `AcDream.Core.Allegiance.AllegianceTree`~~ **[FA1 fix-round addendum, 2026-08-12: `AllegianceTree` was DELETED by Campaign FA slice FA1 (`4281750b`) — there is nothing left to wrap. Wrap `ClientCommandResponses.AllegianceProfileLookups` (the flat `AllegianceMemberRecord` list + `GetData`/`GetPatron`/`FindVassals` walk that replaced it) instead. FA2 is the very next slice — this is its seam-map row.]** | Same; ~~**survives reconnect** — use a `HasServerSeed`-style latch~~ **[FA2 fix-round addendum, 2026-08-12 (docs/research/2026-08-12-fa2-review-mechanism.md MUST-FIX 1): WRONG — retail clears the allegiance profile at `OnEndCharacterSession`, the very same boundary Fellowship clears at. Allegiance is now a `RuntimeGenerationReset` stage exactly like Fellowship; the `HasServerSeed` latch clears AND re-arms every generation (matching the `RuntimeCharacterOptionsState` precedent's actual clear-and-relatch behavior, not the persist behavior this row previously (mis)cited it for).]** | `RuntimeCharacterOptionsState` seed latch; ~~`AllegianceTree.cs:56-162`~~ **[FA1 fix-round addendum: see `ClientCommandResponses.cs:250-295` (`AllegianceProfileLookups`) instead]** |
| Owner registration | `GameRuntime.cs` | ctor + `construction.Own` + fault point + `*Owner` prop + view prop + `CaptureOwnership` + shutdown step | `GameRuntime.cs:200-214`, `:419-429`, `:463-470`, `:545-567`, `:703-752` |
| Session reset | `RuntimeGenerationReset.cs` | new `RuntimeGenerationResetStage` ordinal + `Drain` case; **fellowship clears, allegiance re-seeds** | `:21-44`, `:236-349`; shared-stage example `:248-261` |
| Ownership rollup | `RuntimeGameplayOwnership.cs` | add to record + `Capture(...)` signature + `IsConverged` | `:8-21`, `:23-44` |
| Typed borrowed views | `GameRuntimeGameplayViews.cs` + `GameRuntimeViews.cs:243-272` | `Snapshot` record struct + `TryGet*`; no allocation | `IRuntimeSocialView` `GameRuntimeGameplayViews.cs:90-110` |
| Generation-gated commands | `GameRuntimeCommands.cs` + BOTH adapters | new interface + `IGameRuntimeCommands` member + `RuntimeCommandDomain` ordinal | `IRuntimeSocialCommands` `:291-300`; `DirectGameRuntimeCommandAdapter.cs:718-750`; `CurrentGameRuntimeCommandAdapter.cs:690` |
| Inbound parsers | `src/AcDream.Core.Net/Messages/GameEvents.cs` | static `Parse*` → nullable struct, `null` on malformed | `ParseChannelBroadcast`, `ParseTell` |
| Inbound registration | `src/AcDream.Core.Net/GameEventWiring.cs` (inside `WireAll`) | `registrar.Register(type, e => ...)`; state-object OR delegate hole | `friends`/`squelch` params `:80-81`; `AllegianceInfoResponse` `:192-198` |
| Host bindings plumbing | `LiveSessionEventRouter.cs:72-82` + **both** construction sites | trailing optional params | `LiveSessionRuntimeFactory.cs:256-261`; `HeadlessSessionHost.cs:780-785` |
| Outbound builders (fellowship) | `SocialActions.cs` (already there, `:123-168`) | keep the family together | — |
| Outbound builders (allegiance) | `AllegianceRequests.cs` (extend, `:27-56`) | keep the family together | — |
| Outbound send wrappers | `src/AcDream.Core.Net/WorldSession.cs` (**MISSING — must add**) | `NextGameActionSequence()` + `SendGameAction(builder(...))` | `SendSetSingleCharacterOption` `:2202-2206` |
| App bus path | `LiveSessionCommandRouter.cs` | `*RuntimeCmd` record + `commands.Register<T>(... SendIfActive ...)` | `:74-81`, `:173-186` |
| Wire tests | `tests/AcDream.Core.Net.Tests/Messages/` | field probes + **hand-computed** golden vector for any derived layout | `SocialActionsTests.cs:136-175`; `AllegianceRequestsTests.cs:10-34` |
| Option un-dim | `CharacterOptionsPageController.cs:193-201` + tests | flip `StoreOnly`→`Live` AND edit the literal set + two counts | `CharacterOptionsPageControllerTests.cs:710-766` |
| Panel catalog | `RetailPanelCatalog.cs:10-51` + `WindowNames.cs` | byte-verify the panel id from authored property `0x10000029` | `RetailPanelCatalog.cs:20-29` (the OP3 verification method) |
| Panel mount | `RetailUiRuntime.Mount<X>()` + `Initialize()` list | Import → Bind → `RetailWindowFrame.Mount` → `RegisterMainPanel` | `MountCharacter` `RetailUiRuntime.cs:2663-2706`; ordering `:385-413` |
| F3/F4 handler | `RetailUiRuntime.HandleInputAction` `:548-560` | one `if (action == ...) { ...; return true; }` | `ToggleSpellbookPanel` case `:552-556` |
| Confirmations | `GameplayConfirmationController` (types 1/4) or a new owner | retain `(serverType, serverContext)`, single-slot guard, respond on close | `GameplayConfirmationController.cs:32-101` (its `:36-40` comment names FA) |
| Dialogs | `RetailDialogFactory.MakeConfirmation` `:125-136` | queue key + priority; `OpenNextDialog` early-return on occupied key | `:323-334` |
| Strings | `DatStringResolver.Resolve(tableId, ComputeHash("ID_..."))` | never invent English; log + leave null | `CharacterOptionsPageController.cs:409-416` |
| System messages | `RuntimeCommunicationState.AddText` | `Allegiance 0x12` / `Fellowship 0x13`; `ClientLocal 0x1A` = SpewBox only | `RuntimeCommunicationState.cs:210-239`; `RetailLogTextType.cs:44-45` |
| Bot gate | `src/AcDream.Headless/Policies/HeadlessBotPolicy.cs` new policy + factory id | stage machine, generation-gated commands, `IsComplete` | `LifecycleSmokeHeadlessBotPolicy` `:84-142`; factory `:16-27` |
| Bot config | `HeadlessConfiguration.cs` / `HeadlessConfigurationLoader.cs` | all 6 FA option names already allow-listed | `:27-57`; MF-2 rejection `:252-274` |
| Bot gate script | `docs/research/2026-08-1X-campaign-fa-test-script.md` | OP7 §recipe shape | `2026-08-11-campaign-op-test-script.md:766-895` |

---

## 9. Open questions for the plan

1. **One owner or two?** This audit recommends two
   (`RuntimeFellowshipState`, `RuntimeAllegianceState`) on lifetime
   grounds. If the plan prefers one `RuntimeSocialGroupState`, it must
   still model two independent reset semantics inside one
   `IsConverged`.
2. **Does `IRuntimeEventObserver` gain `OnFellowship`?** Adding a member
   breaks all 5 bot policies + the trace recorder + App observers. Decide
   push-vs-poll before writing the owner. (Recommend poll via
   `Snapshot.Revision`.)
3. **`0x027C AllegianceInfoResponse` already has a handler**
   (`GameEventWiring.cs:192-198`, chat output for `@allegiance info`).
   Does FA extend that lambda, register a second handler, or leave the
   panel to use a different event? ~~The dispatcher permits multiple owned
   handlers per type~~ **[FA2 fix-round addendum, 2026-08-12
   (docs/research/2026-08-12-fa2-review-blast.md SHOULD-FIX 1): wrong —
   `GameEventDispatcher.Dispatch` invokes only the single
   most-recently-registered handler per type; a second `Register` call
   REPLACES, it does not co-own. See §2.3's addendum for the full
   correction. Answered: extend the existing lambda (done), and FA2's own
   fix round then found the extension itself should not exist — retail's
   0x027C handler is print-only, so no owner ever gets fed from it.]** —
   but two handlers writing to two different owners is
   the "two writable copies" smell.
4. **Which of the 6 dimmed rows actually gain consumers in FA v1?** Each
   un-dim requires three coordinated edits (§4.2). Under-claiming is safe;
   over-claiming makes the conformance test lie.
5. **Second ACE account for the two-bot fellowship gate.** CLAUDE.md
   documents only `testaccount`/`+Acdream`. Confirm with the user whether a
   second account+character exists, or whether the gate should use two
   characters on one account (which ACE will not allow simultaneously).
6. **Allegiance gate strategy.** Swearing is semi-permanent and rank-gated.
   Recommend not gating allegiance with bots against `+Acdream`.
7. **`ID_Fellowship_*` / `ID_Allegiance_*` string-table id.** Assume
   nothing — dat-verify. The options family is `0x23000003`, but chat
   filters live in `0x2300000D` and keyboard refusal in `0x23000004`.
8. ~~**`BuildFellowshipCreate` trailing-pad rule** is currently pinned only
   by a self-consistent test (`SocialActionsTests.cs:53-68`), not against a
   retail/ACE reference. Lane A/B should confirm before FA sends it live.~~
   **[FA1 fix-round addendum, 2026-08-12: ANSWERED by FA1, close this
   question rather than re-deriving it. `PackString16L`
   (`SocialActions.cs:389-403`) pads the string record to a 4-byte multiple
   INCLUDING its own u16 length, so `12 + name.Length` is already
   4-aligned before the trailing `u32 shareXP` is appended — the pad the
   old (now-deleted) builder added after its two invented bools was never
   the string's own pad. ACE reads exactly `ReadString16L()` then
   `ReadUInt32()` (`GameActionFellowshipCreate.cs`), and `ACE.Common`'s
   `ReadString16L` skips the identical `CalculatePadMultiple(2 + length,
   4)` pad. The golden vector at `SocialActionsTests.cs:65-83` ("Team",
   len 4, 2 pad bytes) is hand-derived against that ACE reader, not merely
   self-consistent. No further confirmation owed.]**
9. **`DisplayAllegianceLogonNotifications` semantics**: receive-side
   display filter (swallow locally) or membership-style suppression? Unlike
   `Hear*Chat` this is almost certainly display-only — but it must be
   confirmed against retail, not inferred.
10. **Panel ids for `RetailPanelCatalog`.** Must be byte-verified from the
    authored `0x10000029` property, not guessed; the BN literal-0 fold
    artifact bit Campaign OP four times.
11. **Does the FA panel participate in `RegisterMainPanel`'s shared
    geometry?** That gives retail's single-active-child behavior (opening
    Fellowship closes Allegiance) automatically. Confirm that is retail
    behavior for F3/F4 before adopting it.
12. **Divergence register rows.** Any FA-introduced approximation needs its
    row in `docs/architecture/retail-divergence-register.md` **in the same
    commit**; any row FA retires (e.g. #L.4's panel gap) is deleted in the
    same commit.

---

## Executive summary

1. **FA is half-scaffolded already:** all 11 event ids, all 7 outbound
   builders, the `AllegianceTree` model, both chat `LogTextType`s, the
   F3/F4 input actions with retail ActionMap ids, and the MF-2 option
   mutual-exclusion exist — but the builders have **zero production
   callers**, there are **no `WorldSession.Send*` wrappers**, **no
   parsers**, **no inbound registrations**, and **no F3/F4 handler**.
2. **Ownership: two new sibling J-owners under `GameRuntime`**
   (`RuntimeFellowshipState`, `RuntimeAllegianceState`), NOT children of
   `RuntimeCommunicationState` — ~~the lifetimes differ (fellowship is
   session-scoped, allegiance survives reconnect)~~ **[FA2 fix-round
   addendum, 2026-08-12: both are now session-scoped, cleared at every
   generation reset — see §1.3's addendum. They remain separate owners
   because they are independent retail systems, not because their
   lifetimes differ]** and J4's own precedent is
   one owner per coupled graph. Each costs eight mechanical edits, listed
   with line-cited templates in §1.1.
3. **Inbound has exactly one registration site**
   (`GameEventWiring.WireAll`, called only from Runtime's
   `LiveSessionEventRouter.cs:179`), so both hosts are served by one wiring
   — provided the sink is Runtime-owned; both `LiveSocialSessionBindings`
   construction sites (App `LiveSessionRuntimeFactory.cs:256`, Headless
   `HeadlessSessionHost.cs:780`) must be updated together.
4. **Exactly six dimmed rows are in FA's blast radius**
   (`IgnoreAllegianceRequests`, `IgnoreFellowshipRequests`,
   `DisplayAllegianceLogonNotifications`, `FellowshipShareXP`,
   `FellowshipShareLoot`, `FellowshipAutoAcceptRequests`,
   `CharacterOptionsPageController.cs:195-200`); un-dimming any of them
   requires three coordinated edits pinned by
   `StoreOnlyRows_MatchTheDerivationTableExactly` and
   `Bind_AppliesDimmedCaptionColor_ForStoreOnlyRows_AndWhiteForLiveRows`.
5. **A bot-recruits-bot gate needs a second ACE account** (the only
   external prerequisite), a new `HeadlessBotPolicy` id with a role
   discriminator, a friendly-player target query, and 7 named assertions —
   the decisive one being that the *recruited* bot's own snapshot flips,
   which only two live sessions can prove.