diff --git a/docs/plans/2026-08-11-fellowship-allegiance-campaign.md b/docs/plans/2026-08-11-fellowship-allegiance-campaign.md
index ab031f32..6d94b56d 100644
--- a/docs/plans/2026-08-11-fellowship-allegiance-campaign.md
+++ b/docs/plans/2026-08-11-fellowship-allegiance-campaign.md
@@ -150,22 +150,48 @@ served by the single inbound wiring site.
   acdream's `RetailDialogFactory`/`GameplayConfirmationController`
   already match the constants and its own comment names these types as
   awaiting FA. The missing third message of the triple is completed in
-  FA1. The invite-receive path consumes `IgnoreFellowshipRequests` /
+  FA1. ~~The invite-receive path consumes `IgnoreFellowshipRequests` /
   `FellowshipAutoAcceptRequests` (auto-decline / auto-accept before the
-  dialog), giving those two dimmed rows their real consumers.
+  dialog), giving those two dimmed rows their real consumers.~~ **[FA4
+  mechanism-review correction, 2026-08-12 (`913e35cd` MUST-FIX 2): retail's
+  client does NOT read either option bit on the invite/confirmation path —
+  byte-verified across `Handle_Character__ConfirmationRequest @0x005640A0`,
+  `RecvNotice_FellowshipRequest @0x00490880`, and `MakeFellowRequestDialog
+  @0x00490620` (whose ONLY guard is `m_fellowRequestContext`), plus a
+  whole-file sweep of both accessors: zero option reads anywhere on the
+  path. ACE filters both bits SERVER-SIDE. So there is NO client-side
+  auto-response: the fellow-invite dialog (type 4) always shows through the
+  generic `GameplayConfirmationController`, exactly as retail does. The
+  client-side intercept FA4 shipped is removed. `IgnoreFellowshipRequests`
+  defaults TRUE, so a client-side intercept would additionally have
+  silently swallowed real invites against any server that didn't filter —
+  a real hazard, not just a fidelity nit.]**
 - **D7 — dimming resolves per lane-C/D verdicts.** Un-dim (with the AD-78
   conformance-test flow) exactly the rows that gain consumers:
-  `IgnoreFellowshipRequests`, `FellowshipAutoAcceptRequests` (D6), and
+  ~~`IgnoreFellowshipRequests`, `FellowshipAutoAcceptRequests` (D6), and~~
   the fellowship share rows consumed by the create flow/panel display.
   `IgnoreAllegianceRequests` and `DisplayAllegianceLogonNotifications`
   stay dimmed PERMANENTLY and faithfully — retail's own client has no
   consumer for either (pure server-side filters); AD-78's register row
-  gains an addendum saying so.
+  gains an addendum saying so. **[FA4 mechanism-review correction,
+  2026-08-12: following D6's correction, `IgnoreFellowshipRequests` and
+  `FellowshipAutoAcceptRequests` ALSO stay dimmed PERMANENTLY and
+  faithfully — they are pure server-side filters exactly like the two
+  allegiance bits, with no client consumer. FA4's un-dim of these two
+  REVERTS (dimmed count 31 → 33 of 50); only the fellowship SHARE rows the
+  create flow/panel genuinely reads stay un-dimmed. AD-78's addendum names
+  the corrected set.]**
 - **D8 — bot-vs-ACE gates are first-class.** A second ACE
-  account/character (user-provided when FA6 arrives) + a
-  role-discriminated headless policy let one bot recruit/swear at
-  another, with the decisive assertion on the RECRUITED bot's own
-  snapshot. All six FA option names are already tier-1 allow-listed.
+  account/character + a role-discriminated headless policy let one bot
+  recruit/swear at another, with the decisive assertion on the RECRUITED
+  bot's own snapshot. All six FA option names are already tier-1
+  allow-listed. **[User-provided 2026-08-12: the second account is
+  `testaccount2` / `testpassword2` on the same local ACE. RECRUIT REQUIRES
+  PROXIMITY — the recruiting character must be quite close to the recruit
+  target, so the FA6 bot gate must position the two bot characters near
+  each other (same landblock/adjacent) BEFORE the recruit command, or the
+  recruit fails; the FA4 §FA4 [TWO-CLIENT] recruit step notes the same for
+  the manual path.]**
 - **D9 —** ~~the 8 missing fellowship WeenieError strings are added in FA1
   (two are on ACE's live send paths today; all resolve from the DAT
   string tables, never invented).~~ **[FA1 fix-round addendum, 2026-08-12: