From e6d97516e5c39e735f73095bdf423389d2d79221 Mon Sep 17 00:00:00 2001 From: Erik Date: Wed, 12 Aug 2026 07:06:22 +0200 Subject: [PATCH] =?UTF-8?q?docs:=20FA4=20review=20=E2=80=94=20correct=20D6?= =?UTF-8?q?/D7=20(server-side=20invite=20filter)=20+=20record=20D8=20accou?= =?UTF-8?q?nt/proximity?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit D6 asserted the client consumes IgnoreFellowshipRequests/ FellowshipAutoAcceptRequests on the invite path; the FA4 mechanism review (913e35cd MUST-FIX 2) byte-verified retail reads NEITHER bit client-side (Handle_Character__ConfirmationRequest @0x005640A0, RecvNotice_ FellowshipRequest @0x00490880, MakeFellowRequestDialog @0x00490620) — ACE filters both server-side. Same class as the D2 reset-lifetime correction. D6/D7 corrected in-place with dated addenda: the client-side intercept is removed, the invite dialog always shows, and the two un-dims revert (dimmed 31->33). D8 records the user-provided second account (testaccount2/testpassword2) and the recruit-proximity requirement. Co-Authored-By: Claude Fable 5 --- ...26-08-11-fellowship-allegiance-campaign.md | 42 +++++++++++++++---- 1 file changed, 34 insertions(+), 8 deletions(-) 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: