Plan doc with twelve slices, dependencies, review protocol (Opus
dual-lens: architectural + retail-faithful), and ledger. Three parallel
recon reports grounded the slice bodies:
- Retail select screen is gmCharacterManagementUI: flat listbox +
Enter/Delete/Restore + dialogs. NO 3D preview (that machinery is
chargen-only gmCG3DView) — the spec 3D-preview slice is deleted, the
old retail-ui/05-panels.md pedestal claim is uncited and wrong.
Restore + CharacterError join scope; delete sends account+slot.
- Chat-command core (parser/router/catalog/ChatVM) is dependency-clean
BCL+Core; extraction to Runtime is a move, not a rewrite.
- Probe reuses the NoCharacters early-exit shape (graceful teardown at
the CharacterList stage exists today); roster plumbing is new.
- Bake tool needs --progress-json + explicit --out; no whole-file SHA
exists — launcher records/verifies its own.
- UI Studio is deleted (Campaign V) — stale references corrected.
Roadmap + CLAUDE.md Current state carry the campaign pointer.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Approved brainstorm outcome for the alpha launcher campaign: Approach A
file-contract orchestrator (session config in, stdin credential, JSONL
status events out), full in-UI CRUD for servers/accounts/credentials,
headless character-list probe, retail character-select screen (no
Create), plugins + login commands on both hosts, first-run DAT
locate/bake install, GitHub Releases update feed.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
ISSUES: #372/#374/#375/#378-#382/#385 flipped DONE (re-gate USER-PASSED
2026-08-14); #396 records the live-verified crash fix. CLAUDE.md Current
state: Campaign OP paragraph now carries the 2026-08-14 round and the
still-owed full OP3-OP6 sections + OP8 visual re-check.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The user's first click on a mapping button killed the client: the live
dialog catalog's wait root 0x31 carries retail class type 0x19 (WaitDialog),
which DatWidgetFactory left unmapped, so the root built as a plain
UiDatElement and RetailWaitDialogView's ctor threw out of UiButton.OnClick
into the render loop. The unit test missed it by standing the confirmation
fixture (type 0x13, mapped) in for the wait root — the structural-false-
negative class again. Pins: DatWidgetFactoryTests theory for both dialog
root types, plus an installed-DAT UiDialogRoot/0x3D/0x3E assertion in the
env-gated keyboard probe. OpenCaptureInstructions now converts a dialog
construction failure into its contracted 0-return (log + capture refused,
retail's own OpenMapWarnDialog failure shape) instead of crashing.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Three findings from the user's first Configure Keyboard look (OP8 gate,
2026-08-14), each root-caused against the named retail decomp:
- #394 row-caption font: the synthesized action-label UiText never set
DatFont and fell to the debug bitmap font. The authored row template
(0x21000009/0x1000002F, retail UIOption_ActionKeyMap) carries FontDid
0x4000000A (18px serif) — Bind now takes resolveTemplateFont and applies
the template's own authored font, resolved once per template pair.
- #395 key captions: raw enum spellings ("Shift+ShiftLeft") replaced by the
port of CInputManager_WIN32::GetNameFromKey @0x00687F40 /
GetNameFromKey_Internal @0x00687800 (RetailKeyNames): DAT string-table
override by DIK-name hash (key enum 4 -> 0x2300000A, meta enum 5 ->
0x2300000B, delimiter enum 3 -> 0x23000007 — GetDIDByEnum category 4,
live-probed), else the OS keyboard layout's own key name ("SKIFT") via
PlatformKeyNameProvider (Win32 GetKeyNameTextW — register row AD-96 for
the DirectInput-vs-GetKeyNameText adaptation), else the DIK-suffix
spelling. Bare modifier-key bindings show only the key name.
- #396 capture feedback: clicking a mapping button now opens retail's
instruction dialog (InitiateBinding @0x004899D0 -> OpenMapWarnDialog
@0x00488A00): a type-2 WAIT dialog on retail's MapWarn queue key
0x10000001 with ID_ActionKeyMap_MapInstructions (0x23000004, ACTION
variable interpolated), closed on key hit or ESC through the capture
callback; capture is not armed if the dialog cannot open, matching
retail. New RetailWaitDialogView (wait root 0x31 — same authored
popup/message pair 0x3D/0x3E as the confirmation root, live-DAT probed)
behind a shared IRetailDialogView presenter seam.
Probe evidence (env-gated, kept):
KeyboardConfigLiveMountProbeTests.ProbeKeyboardFontsAndKeyNameStrings.
Register: AD-96 filed. Gate script OP8 section updated (step 4 rewritten;
the "pressed/active state is enough" contract is retired).
Full Release solution suite green (13,424 passed / 4 skips).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The two-client user gate PASSED 2026-08-14 (open both ways, stage with
the retail trading marker, accept/decline, executed swap, Clear All,
cancel text). Every TEMPORARY [trade] probe line from gate rounds 1-2 is
stripped (ItemInteractionController, SelectionInteractionController,
SecureTradeUiController, LiveSessionCommandRouter, WorldSession,
RuntimeTradeState). Roadmap gains the shipped-trade ledger row.
Suites after strip: App 4,992/3, Runtime 1,626 - green.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
staged-item trading marker
- Cancel text: ClientTradeSystem::Handle_Trade__Recv_CloseTrade
@0x0056DE30 shows "The trade has been cancelled." UNCONDITIONALLY
(every close reason) as 0x1A ClientLocal - the yellow top-center
SpewBox line. Wired at the router's onTradeClose beside ApplyClose;
the string lives in ClientTextRefusals with its citation.
- Staged-item marker: retail's mechanism decoded end-to-end - the
UIItem prototype (catalog 0x21000037) authors overlay child
0x10000438 (sprite 0x06001DAE, the green frame + corner trade icon),
bound @0x004E18FC and SetVisible(tradeState != 0) @0x004E2420;
gmSecureTradeUI::AddItem @0x004CA801 sets
ACCWeenieObject::SetTradeState(1) on YOUR staged items. Ported as:
UiItemSlot.ShowTradeOverlay + TradeOverlaySprite (drawn over the
icon), set on the trade window's self-grid cells; and
RuntimeTradeState now borrows the canonical object table and
maintains ClientObject.TradeState (1 at stage, 0 at remove/failure/
reset/close/clear) - which also brings the ALREADY-PORTED placement
policy's "You cannot move an item while it is being traded" refusal
to life (its input field previously had no live producer).
Runtime 1,626, App 4,992/3 - green.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
root cause for every dead interaction) + retail's Total Items caption
The round-2 probes nailed it: the request seam fired for BOTH open
paths (use AND drag - "drag-release pick" -> "drag-on-player" ->
"request"), but no open-cmd, no wire-open, and no LiveCommandBus
drop-warning ever printed. MountSecureTrade captured
_bindings.Options.CommandBus() ONCE at mount time - the pre-session
surface whose Publish routes into a null route silently. CommandBus is
a Func for exactly this reason; the social mounts resolve it inside
each lambda. Every trade command - open (use + drag), accept (the
"unpressable" Trade button - the click FIRED, the publish died),
Clear All, close, and drop-on-grid staging - died on that one captured
bus. All six lambdas now resolve the Func per call.
Also: ID_SecureTrade_TotalItemsLabel probe-verified token-free
(fragments ["Total Items: ", ""], one ITEMS variable 0x004E8A23) and
composed via ResolveTemplate - the count texts read retail's exact
"Total Items: N". AD-95 RETIRED same-day.
The pre-feature stub-toast test row (drag-on-player option-on expecting
"Secure trade is not open.") now pins the SecureTradeRequested seam
instead. App suite 4,991/3 skips.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
layout-persisted; deeper [trade] wire probes
A session that ended mid-trade saved Visible=true for "secure-trade" in
the window-layout file, restoring an empty open trade window at every
launch. Added to the stateManagedVisibilityWindows set beside
Combat/JumpPowerbar/ExternalContainer/Vendor - visibility belongs to
RuntimeTradeState's open/closed lifecycle exclusively.
Also carries the round-2 [trade] probes for the still-open "open never
registers" diagnosis: the round-1 log proved the request seam fires
(4x "request partner=0x50000001 item=0 open=False") but no window ever
opened - the new probes bracket the command router (open-cmd sent
flag), the wire send (wire-open seq), and the inbound RegisterTrade
apply, so the next gate log pinpoints whether the send leaves the
client and whether ACE replies.
App suite 4,990/3 skips.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
and [trade] seam probes
- Use on a selected player did nothing: the world Use path
(SelectionInteractionController.RequestUse) dispatches 0x0036 directly
and NEVER consults DetermineUseResult - lane C's "both paths already
classified" claim described the POLICY's capability, not a live
caller (the verify-subagent-claims lesson, again). Retail's
CPlayerSystem::UsingItem @0x00562F70 consults it and routes result 5
(another PLAYER) to AttemptToOpenTradeNegotiations @0x0056DEE0, peace
mode only, with no Use send. Ported as
ItemInteractionController.TryOpenSecureTradeWithPlayer, called at
RequestUse entry.
- The broken window: both grids rendered their raw authored strip art
with no cell layout (the gold-ring tile was the naked track). They now
get the vendor strips' exact single-row 32px config + the authored
empty-slot art resolved through ItemListCellTemplate (cell-template
attr 0x1000000E -> 0x1000033A).
- Drag-onto-player "nothing happens": the policy chain reads correct
end-to-end in code (pick -> PlaceIn3D -> StartSecureTrade -> event ->
cmd), so TEMPORARY [trade] probe lines now bracket every seam
(drag-release pick, policy arm, controller request, use-on-player) -
the next gate log pinpoints the break if it persists. Stripped once
the two-client gate passes.
App suite 4,990/3 skips.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
authored gmSecureTradeUI window, and both retail open paths
Three-lane research first (docs/research/2026-08-14-trade-lane{A,B,C}):
retail gmSecureTradeUI decode, the byte-exact ACE/decomp/holtburger
three-way wire agreement, and the acdream seam map (which found both
open paths ALREADY classified by the ported policy - OpenSecureTrade on
Use-a-player, StartSecureTrade on drag-item-onto-player with the
DragItemOnPlayerOpensSecureTrade option - dead-ending at a stub toast).
- Core.Net: TradeRequests builders (0x1F6-0x204, retail's CM_Trade
senders byte-checked against ACE's readers; the ACE-discarded
AcceptTrade echo carries zero-count item lists - AD-94), corrected +
completed inbound parsers (0x1FD-0x208; the old AddToTrade parser
missed the SIDE dword, TradeFailure missed the reason), delegate-hole
registrars, six WorldSession sends. 10 golden-byte tests.
- Runtime: RuntimeTradeState, the third sibling J-owner (fellowship/
allegiance shape): session-scoped, clears at generation reset (new
stage Trade=14), staged teardown stage 11 (Identity/EntityObjects
shift 12/13, TeardownStageCount 14 - the FA2-era per-stage-flag test
caught the mapping exactly as designed), combined ownership ledger,
event routing with ACE's wrong-initiator RegisterTrade landmine
honored (partner = whichever guid is not mine). 7 conformance tests.
- App: SecureTradeUiController binds the dedicated authored LayoutDesc
0x2100000D (root 0x1000007A - gmSecureTradeUI::PostInit's exact ids):
partner name/status/count/grid, the authored 'Trade' accept toggle
(accept <-> decline withdraw), 'Clear All' (ACE clears BOTH sides -
surfaced honestly), the X close, drop-on-your-grid staging, per-mode
accept cues (partner icon's authored Highlight state + Trade button
Selected latch). Mounted via the vendor recipe (nine-slice chrome,
hidden until RegisterTrade). ItemInteractionController's two policy
arms now raise SecureTradeRequested instead of the stub toast; the
drag path queues the dragged item until the window registers
(ClientTradeSystem::AttemptToTradeItem @0x0056DF80's shape).
Register: AD-94 (accept-echo zero-count lists), AD-95 (numeric-only
count texts pending template verification).
Suites: App 4,990/3, Core.Net 905, Runtime 1,626 - all green. The
panel itself is user-gate acceptance (two-client connected trade), the
#372-class lesson: fixture-green alone is not acceptance for a mount.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
From the 2026-08-14 highres verification: acdream always runs at retail
MAX texture detail (Textures[0] + unconditional client_highres.dat).
Retail's two knobs (ID_Option_HighResChange gating LoadHighResDat
@0x004FA250; Landscape/Environment TextureDetail as a mip-chain start
index @0x0044C3C8) are recorded with their decomp anchors and the
acdream-side seams. Post-M4.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
machine + UiText per-state string swap (user retail gate)
The state side already worked (FriendsState replaces the full entry and
bumps Revision on 0x0021 OnlineStatus updates; the parser reads full
FriendData for every update type). The UI side had two gaps, exposed by
the installed-DAT row-template probe (template layout 0x2100005D root
0x10000519):
- The row authors TWO cells: the LEFT name text 0x1000051A whose
Online (0x10000054) / Offline (0x10000055) PassToChildren states
cascade into the RIGHT status grandchild 0x1000051F, which authors
per-state 'Online'/'Offline' strings AND per-state colors (retail's
green Online). The controller's FindDeepest binding wrote the NAME
into the STATUS cell (the deepest text IS the status grandchild) and
never flipped the state machine - so the status column never showed
or updated anything.
- UiText had no per-state authored-string swap: ApplyDatState switched
sprite + color per state but never the 0x17 string. Ported now
(second consumer of the mechanism after the powerbar caption):
DatWidgetFactory pre-resolves each state's authored string;
TrySetRetailState swaps the line, colored by the SAME state's
authored 0x1B.
SocialFriendsPageController now binds the name to its own cell and
flips the authored Online/Offline state per friend on every
Revision-driven rebuild - the cascade renders the status cell exactly
as retail's gmFriendsUI does, green Online included.
App suite 4,989/3 skips (new per-state swap conformance test).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
gate; supersedes CH round-1 item A)
The user's retail description matches the decomp exactly:
charge_jump @0x005281c0 has NO grounded check - it refuses only 0x49
(CanJump encumbrance) and 0x48 (fallen/crouch-family forward commands).
Pressing jump while airborne begins the powerbar and charges normally.
The 0x24 "You can't jump while in the air" comes exclusively from the
RELEASE path (ClientCombatSystem::DoJump @0x0056B110 ->
CMotionInterp::jump -> jump_is_allowed, whose airborne 0x24 our port
already carries test-pinned). A charge held through landing executes a
normal jump on the grounded release.
PlayerMovementController's input orchestration now mirrors
CommenceJump/DoJump:
- Press edge: ChargeJump() decides; a refused charge (0x48/0x49)
reports and never begins the bar (retail's jump_pending stays 0).
The invented airborne press-edge 0x24 report (CH user-gate round 1
item A - added when the press/release split was not yet known) is
deleted; CommenceJump's in-air fallback text is unreachable with a
faithful charge_jump.
- Hold: accumulates grounded OR airborne; leaving the ground mid-charge
no longer force-fires the jump.
- Release: fires jump(); an airborne release refuses 0x24 there.
Tests: the round-1 press-edge test is replaced by two release-semantics
tests (airborne release reports once; held-through-landing grounded
release jumps silently). Runtime 1,619, App 4,987/3, Core jump family
159.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
gate; the DAT authors it)
The raw-property probe settles it exactly as the user reported: the
powerbar caption's mode STATES author their OWN justification (0x14
Enum=0x3 = Right on JumpMode/MeleeMode/MissileMode) while the element
default stays centered. ElementInfo.HJustify only ever read the
effective DEFAULT state, so the earlier "authored Center" conclusion
measured the wrong state.
The meter's absorbed state-label entry now carries the state's own
authored alignment (state 0x14 wins, element-level HJustify as the
fallback, ElementReader's same enum mapping), and the caption draw
aligns accordingly - 'Height' sits at the bar's right edge, retail's
placement. Live vitals labels keep their centered draw.
App suite 4,987/3 skips.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Retail authors ONE caption element per bar with per-mode state strings,
switched by a PassToChildren state cascade (gmPowerbarUI::
RecvNotice_BeginPowerbar @0x004DA730 sets 0x10000042 Jump / 0x10000043
Melee / 0x10000044 Missile / 0x10000045 DDD; installed-DAT probe
confirmed every string + PassToChildren flag).
- Jump bar (user gate): the floaty powerbar's caption child (0x10000035:
JumpMode 'Height', authored HJustify=Center over the bar) was dropped
by UiMeter's child absorption. The stateful-fill meter build now
absorbs it into per-state labels; TrySetRetailState latches the
caption and OnDraw shows it when no live Label provider is bound.
JumpPowerbarController's existing JumpMode flip now surfaces 'Height'
with zero controller changes. The mount gained the string resolver the
Build call never passed.
- Combat bar (user gate): label 0x10000052 authors 'MeleeCombat' ->
'Power' and 'MissileCombat' -> 'Accuracy'; the controller latched the
MELEE string once at bind. CombatUiLabels now resolves both authored
strings and OnCombatModeChanged sets the mode's string - switching
live when swapping melee <-> missile weapons in combat. Also fixed
the mode-state flip target: the states live on the BASIC PANEL
(0x1000005C, PassToChildren), not the layout root (Hide/ShowDetail
only) - the old _root flip was a silent no-op.
New env-gated ACDREAM_PROBE_POWERBAR layout probe (kept, house
pattern). App suite 4,987/3 skips.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
move-cursor border band
- Empty-state text (round 3): the literal-\n split was correct but each
authored LINE rendered as one clipped run. Retail word-wraps each
authored line within the element extent (its GlyphList draw - the
same wrap RetailConfirmationDialogView already uses). Multiline
authored text now wraps through UiText.WrapWords against the widget's
LIVE width/font/color (cached per width+font+color, re-read per call).
Single-line authored labels keep their one-run shape - re-wrapping
every label is a client-wide change no gate asked for.
- Move cursor (round 3): "the frame won the hit-test" is not a border
test - windows whose interior is not fully covered by children (the
inventory panel's empty regions) resolve those pixels to the frame
too. The border is now a geometric 8 px band along the window's outer
edge, AND the frame must win the hit-test so border-adjacent content
keeps its own cursor. Resize-edge claim still takes precedence;
whole-surface dragging unchanged.
App suite 4,984/3 skips (new BuildText_MultilineAuthored wrap test).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
refused-drop yellow notice
Item 4 (confirmation dialogs missing text + names): the missing retail
mechanism was StringTable template substitution - an entry is N+1 literal
fragments interleaved with N named variables, composed by
StringTable::GetString @0x004300D0 (no-metalanguage branch @0x004303B7).
ACE sends the bare player name for types 1/4; retail's OWN CLIENT wraps
it. Ported as DatStringResolver.ResolveTemplate (PLAYER hash 0x05506DA2,
the exact compute_str_hash space; Chorizite stores the variable hashes
directly):
- Server-driven type 4 -> ID_Fellowship_FellowshipRequest, type 1 ->
ID_Allegiance_AcceptSwearConfirmation, injected into
GameplayConfirmationController; null resolve falls back to the bare
wire message, never invented English. The 2/3/5/6 " Continue?" family
never consults the composer.
- Local Swear/Break/Kick: the bind-time fragment-0 latch (which showed
the dangling "Do you wish to swear to ") is replaced by click-time
ResolveTemplate with the target's name.
All five templates verified token-free in the installed DAT - this is
NOT a StringTableMetaLanguage port (AD-81's engine caveat stands).
Item 5 (refused drop shows nothing; retail shows yellow top-center
text): the prevRequest latch was ALREADY ported (InventoryTransactionState);
what was missing was the consumer. InventoryTransactionState now raises
RequestFailed(request, weenieError) when a 0x00A0 clears the latch;
ItemInteractionController composes ServerSaysAttemptFailed @0x0058EAE0's
"The <item> can't be <verb>" (verb table + suffix map ported verbatim in
Core's InventoryFailureMessages, NAME_PLURAL for merge/split) and routes
it as LogTextType 0x1A ClientLocal -> the SpewBox, retail's yellow
top-center line. The dispatcher's second leg (@0x0055B342) also runs:
outside the 7-code exclusion set, WeenieErrorMessages resolves per-code
text/destination; 0x426 AttunedItem has no row in either place beyond
the verb line - faithful single-line output.
Register: AD-85 narrowed to its numeric-field item, AD-81 amended (the
token-free interleave is now ported; meta-token engine + FormatName
remain), AD-93 filed (wire-guid-match vs retail's latched-guid
preference; no Move/Wield latch kinds).
Tests: +2 InventoryTransactionState failure-latch, +5 ResolveTemplate
(constructed StringTable fixtures), +1 composer injection, +1 end-to-end
refused-drop line. Core 4,697/1 skip, App 4,983/3 skips.
Research: docs/research/2026-08-13-confirm-and-weenie-error-display.md
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
empty state, retail amber row selection
- Move cursor (user-directed, ALL windows): HoverWindowMove now
advertises only where the window frame element itself wins the
hit-test - its border pixels; interior points resolve to content
children. Matches retail's Dragbar-chrome-only move cursor.
Whole-surface dragging still works, it just does not advertise.
- Empty-state text (round 2): the DAT stores the LITERAL two-character
escape backslash-n (probe-verified - the dump printed the escape, not
line breaks), so the round-1 newline split never matched. Escapes are
normalized before splitting in DatWidgetFactory authored text.
- Selected fellow amber (user: "check retail"): probe-verified - the
row name band 0x10000282 AUTHORS the retail selected-row art
(DirectState 0x06001450 + Highlight 0x06001451, the amber). Selection
flips the band's ActiveState to Highlight; no invented tint.
App suite 4,976/3 skips. Confirmation-text + refused-drop-notification
research (the round's items 4-5) lands as part 2.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
One user-ordered batch across the FA social panel + world selection.
Every root cause was probe-proven before the fix (new
ProbeSocialClickRouting in SocialPanelLiveMountProbeTests - production
window mount + real UiRoot hit-tests + a synthetic click):
1. STUCK CHECKBOXES (fellowship x4, allegiance x1, "always checked /
can't change any options"): the authored checkboxes carry DAT
ToggleBehavior, so UiButton SELF-FLIPS Selected at MouseUp - the old
handlers read the flipped value and wrote the ORIGINAL back, snapping
every click to where it started (the probe recorded (id, oldValue)).
Fix: SuppressSelfToggle (the CH6a/b mirror discipline) + derive the
next value from the STORE; the per-tick seeding mirrors it back.
2. UNCLICKABLE ROSTER ROWS ("only get the move window cursor"): the row
name text is display-text ClickThrough=true, which the hit-test walk
skips regardless of HandlesClick - the wired OnClick was unreachable.
Fix: UiText.OnClick assignment now clears ClickThrough (central,
documented); the stats text gains the same select handler so most of
the row's width selects the fellow.
3. TRUNCATED EMPTY-STATE ("You do not belong... To create MISSING"):
the authored string resolves COMPLETE (three sentences) but embedded
'\n's rendered as one clipped line. DatWidgetFactory now splits
authored strings into one Line per newline, with the provider still
re-reading DefaultColor live (the state-color contract - caught by
BuildText_AuthoredLineTracksStateFontColor).
4. FELLOW NAMES WHITE (user-directed): the AD-82 invented leader-gold +
selection-blue tints are deleted; names always white (register row
narrowed).
5. ALLEGIANCE HEADER LABELS: bare "0"/"0" -> "Followers: N" / "Rank: [N]"
(user-specified format; the full retail StringInfo composition stays
AD-85's gap), monarch block matching.
6. FRIENDS/SQUELCH LIVE (AD-79 mostly retired): Add friend (name box ->
0x0018, retail clears the box - Request_AddFriend @0x0048D240),
Remove (row-click selection -> 0x0017), Appear Offline (CharacterOption
0x27 via the immediate 0x0005 auto-save, ACE pushes FriendStatusChanged
to your friend-of list), Squelch Character/Account add-by-name
(0x0058 guid0/type AllChannels + 0x0059) and Remove for the selected
row. The wire beneath (builders, WorldSession sends, Runtime commands,
parsers) existed end-to-end since J4.1/FA1 - this is panel wiring only
(docs/research/2026-08-13-social-wire-completion.md, committed here).
Send Tell stays inert (not in the order; AD-79's remainder).
7. WORLD SELF-SELECTION ("clicking my own char should select myself"):
retail has NO self-exclusion (CPhysicsPart::Draw @0x0050D823 arms
every physobj; RecvNotice_SmartBoxObjectFound @0x004E5BAE selects
unconditionally) - the includeSelf gate was an unregistered
divergence, now removed on both the left-click and right-click paths.
Element roles were probe-measured, never guessed (Add 0x10000514 /
Remove 0x10000515 / Send Tell 0x10000516 / Appear Offline 0x1000052C /
name field 0x1000051B; Squelch: field 0x10000540, Remove 0x10000547,
Squelch Character 0x1000054B, Squelch Account 0x1000054C).
Register: AD-79 mostly retired, AD-82 narrowed. Known remainder, filed
not hidden: the fellowship page's authored 600px content vs the 362px
viewport leaves Dismiss/Assign-Leader below the fold until the window is
resized taller (probe-measured; candidate follow-up).
Tests: Checkbox_Click fact rewritten to the mirror contract (both
directions), monarch-followers label updated, includeSelf expectation
updated, probe extended (click routing, synthetic click, action-widget
role dump). App suite 4,976/3 skips.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
position memory, unified monitor, maximized restore; AD-92
Dual-lens Opus review of e56aa511 (reports committed under
docs/research/). The consolidated corrections:
- Mechanism M1 (load-bearing): on Windows, Silk's GLFW error callback
QUEUES exceptions on a static list instead of throwing - they detonate
later at window close, which is exactly #388's original two-stage
crash shape. catch(GlfwException) was dead code here and a failed
SetWindowMonitor "succeeded". Success is now judged by the NATIVE
POST-CONDITION (GetWindowMonitor after the call) on both enter and
exit; the catches remain only for the throwing platforms.
- M2 (both lenses): same-mode fullscreen re-apply is a no-op BEFORE any
native work (new IDisplayModeSwitcher.CurrentFullscreenMode). Every
Display-backed Config row applies per change - sliders per DRAG TICK -
so without this every tick while fullscreen re-issued a real
display-mode change.
- M3/M5 (both): the remembered windowed placement is process state (two
target instances exist - startup and live-save); a fullscreen boot now
exits through either instance to the real placement, not the (60,60)
literal.
- M4 (both): the switcher resolves the WINDOW'S monitor (attached
monitor when fullscreen, else IWindow.Monitor's index into the GLFW
array - the same monitor DisplayModeCatalog enumerated), primary only
as a last resort; the offered-list/switch-target mismatch is gone.
- Blast M2b: the offered-mode validator falls back to the SAME static
ladder the dropdown falls back to - Full Screen is no longer a
permanent silent no-op on catalog-less hosts (the switcher's own
monitor-mode-list check remains the hard guard).
- Blast M3: a windowed pick on a MAXIMIZED window restores it first
(Size writes are silently ignored while maximized; the deleted
WindowState=Normal write used to do this incidentally). New
IWindowedSizeSurface.IsMaximized/Restore.
- Mechanism M5: no silent bail-outs - the unparseable-resolution
fullscreen path logs, and the failure line no longer claims "staying
windowed" when the state is unchanged (#392 noted inline).
- Q1 nit: one cached Glfw wrapper (per-call GetApi allocated + took a
native refcount); IsFullscreen/CurrentFullscreenMode guarded.
- AD-92: highest-refresh-for-WxH + refuse-and-log versus retail's
pass-through-and-error ForceDisplayResolution.
Known-open tail, filed not hidden: #392 (persisted-flag divergence on a
refused enter - needs an apply-result seam); the mechanism report's
pacing-refresh WATCH rides the same seam.
Tests: +3 (same-mode no-op, unparseable-while-fullscreen refusal,
maximized restore-before-write). App suite 4,975/3 skips.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Slice 5+6 of the display block, one coherent unit (they share the state
machine the goal's dual review covers).
GlfwDisplayModeSwitcher (#376) ports retail's fullscreen semantics -
Device::ForceDisplayResolution @gmClient::Init 0x004047af is a REAL
video-mode change - through native glfwSetWindowMonitor on the same
IWindow.Native.Glfw handle path #348's cursor cache proved. Primary
monitor (retail's primary display device); refresh = the monitor's
highest for the picked WxH; the windowed placement is remembered for the
exit path; every failure is a no-throw (bool, reason) result.
SilkRuntimeDisplayWindowTarget.Apply (#388) becomes the state-aware
machine: fullscreen target = validated native mode switch (mode must be
in #391's DisplayModeCatalog - an offered mode is supported by
construction, making the "Graphics mode not supported" crash class
unreachable from the dropdown); windowed target while fullscreen = the
native exit (which sets the client size itself); plain windowed pick =
the proven #387 size write. A raw Size write NEVER happens against a
fullscreen window - on GLFW that is a video-mode request, and an
unsupported one was the exact unhandled-GlfwException that killed the
user's 2026-08-13 session. The old Silk borderless WindowState path is
deleted from the apply. New IWindowedSizeSurface narrows the window
dependency so the machine is unit-testable (FakePacingSurface idiom).
Live-verified on this machine (goal-sanctioned automated run):
display: fullscreen mode switch 1920x1080@300 -> framebuffer resize
event 1920x1080 -> vulkan: swapchain recreated 1920x1080 ok=True ->
graceful close, desktop mode restored.
Tests: 5 state-machine facts (validated switch/never-size-write,
unoffered refusal, failed-switch usability, native exit, plain windowed
write). App suite 4,972/3 skips. Gate script sections D4-D6 written
(black-screen-risk steps flagged). Dual Opus review of the pair follows
as its own round.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Decomp-first per the block's rule: the research doc
(docs/research/2026-08-13-retail-ui-display-change.md, committed here)
pulled retail's actual mechanism before any code. A display change runs
UIElementManager::RefreshEvent @0x0045C530 ->
UIElement::UpdateForParentSizeChange @0x00462640, which unconditionally
re-applies every floating window's own clamping MoveTo override
(x = max(0, min(x, parentW - selfW)) - top-left priority, oversized
windows pin to 0), then broadcasts global message 0xE whose sole
listener reloads the per-resolution auto layout. No proportional moves,
no resets; retail saves layouts only via @saveui.
Port: RetailWindowLayoutPersistence.ClampAllToScreen() is the cascade
clamp (no store I/O; _restoring suppresses the per-move save so a live
drag-resize cannot write settings.json per frame), and
RetailUiRuntime.Draw carries a two-step screen-size edge detector:
change frame -> clamp; first stable frame -> one
RestoreAll(saveBack:false) per-resolution reload (the 0xE analog; no
lazy save-back, matching retail's save-only-on-command). The login
restore path already used retail's exact clamp math (Apply) - the live
trigger was the missing half, which is precisely the stranding the user
reported.
Deliberate deviation, register AD-91: retail's gmFloatyChatUI windows
have NO clamp and can strand; the block's requirement ("UI windows must
stay reachable") clamps every registered window uniformly.
Tests: 5 new persistence facts (clamp/top-left-pin/no-move/no-save-on-
clamp/no-save-on-live-reload). App suite 4,967/3 skips. Gate script
section D3 filled in.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Dual-lens Opus review of 7e0c1303 (reports committed under
docs/research/). The law, gate, and vertical application are CONFIRMED
at instruction-byte level against the PDB-paired acclient.exe (the BN
text FPU-elides this whole area); the fix round addresses the findings:
- Blast MUST-FIX 1: real schema migration instead of a hand-edited dev
file. SettingsStore v2->v3: a pre-v3 display.fieldOfView was the
applied vertical FOV in degrees; v3 means retail's m_fGameFOV.
LoadDisplay migrates on read - the untouched old default 60 maps to
the retail default 90; a deliberate other value preserves its visible
16:9 framing (x (16/9 - 0.1)), clamped to the registered [10,160];
the next save stamps v3 and migration never reruns. The dev
settings.json hand-edit was reverted so the migration owns it.
- Blast MUST-FIX 2 / mechanism M2: the Field of View now applies LIVE on
Save (retail: Render::GRPCallback_OnRenderPreferenceChanged @0x0054d999
-> SmartBox::SetDefaultFov). RuntimeSettingsTargets gains the camera
graph and applies through ApplyDisplayWindowState - the update-phase
seam, deliberately NOT the render-phase preview path (the review's
WATCH-3 cull-vs-raster landmine).
- Mechanism M1 -> register row AD-90: retail's divisor aspect runs
through the Render.AspectRatio preference (ComputeAspectForViewport
@0x0054f150, (w/h) x pref x 0.75) - exactly raw w/h at the registered
default, which is what acdream assumes; retail's NaN-through-the-gate
quirk (M3) is folded into the same row as deliberately not reproduced.
- Docs: RetailFieldOfView now cites the decisive vertical proof
(D3DXMatrixPerspectiveFovLH fovy slot @0x0059ab71), the unconditional
SmartBox::RenderNormalMode site, and M4's exact horizontal numbers
(89.0/83.9/80.6 deg); the Config FOV row comment updated to LIVE.
- Blast WATCH 4 disposition: the 15 replay-harness PI/3 constants stay -
they are CAPTURE-TIME camera parameters for recorded fixtures, not
production framing; changing them would invalidate the replays.
Tests: +6 SettingsStore migration facts, +1 live-apply fact.
App suite 4,962/3 skips; UI.Abstractions 922.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
User-directed (2026-08-13): "we should only support modern resolutions.
Not any old format." New DisplayModeCatalog enumerates the window's
monitor (Silk IMonitor.GetAllVideoModes) once at GameWindow load and
curates via a pure, tested rule: modern widescreen families only
(16:9/16:10/21:9/32:9 within 2.5%), at least 1280 wide, must fit the
desktop (an impossible windowed pick is not offered - the measured
3840x2160-on-2560x1440 silent clamp class), desktop mode always
included, refresh-rate duplicates collapsed, ascending order.
The Config Resolution row consumes the catalog through two new optional
Bind parameters; its Defaults value becomes the desktop's own mode.
Fixture/headless callers keep the static preset ladder, which now drops
800x600 and is pinned by test to pass the same curation rule (the OP6 S4
"default must be re-selectable" invariant holds on both paths).
Deliberate retail deviation, register row IA-22: retail listed the
adapter's complete enumeration including 4:3 legacy modes and authored
800x600 as the Config default (gmConfigUI::InitOptions
SetDefaultValue(0x03200258); gmClient::Init @0x004047af). The catalog is
also the designated fullscreen mode-switch validation source for
#376/#388 - an offered mode is supported by construction.
Tests: DisplayModeCatalogTests (8 - filter/clamp/dedupe/sort/ultrawide/
desktop-inclusion/fallback-consistency); ConfigOptionsPageControllerTests
row-12 default updated. App suite 4,961/3 skips; UI.Abstractions 916.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Retail's world-camera FOV is not a constant: the applied vertical FOV is
m_fGameFOV / (viewportAspect - 0.1), recomputed on every aspect or
game-FOV change (CreatureMode smartbox sites 0x00452b2f/0x00453b14),
gated by Render::SetFOVRad's open (0, pi) acceptance (0x0054b2d0 -
rejected results keep the previous FOV). m_fGameFOV defaults to pi/2 =
90 degrees (0x00454649) and is what the Field of View option sets in
degrees (0x00451e6a; registered range [10,160] default 90 -
gmClient::InitUIPreferences @0x004035b0). Net effect: the horizontal
view stays ~85-90 degrees across aspect ratios; wide screens trim the
vertical slice instead of ballooning the sides.
acdream hardcoded FovY = pi/3 = 60 degrees on all four world cameras,
aspect-independent, and the Config slider wrote raw vertical-FOV
degrees. New: RetailFieldOfView (the law + gate, decomp-cited),
CameraController.GameFovRadians + SetGameFov + one ApplyProjection
chokepoint recomputing every camera on SetAspect/SetGameFov/
EnterChaseMode/RestoreState; ApplyFieldOfView now feeds the law;
DisplaySettings.Default.FieldOfView 60 -> 90 (the retail registered
default; the stored number changed MEANING with this commit).
The same seam closes a second latent bug the 2026-08-13 "squished" gate
report exposed: SetAspect only ever updated Orbit/Fly - the CHASE
cameras (the ones the player looks through) kept their creation-time
aspect across every mid-session resize, drawing the world at the old
shape stretched onto the new viewport.
The paperdoll camera stays outside the law by design (retail portrait
mode is UseSharpMode, not smartbox - DollCamera's own doc).
Tests: RetailFieldOfViewTests (golden law values at 4:3/16:9/21:9, the
constant-horizontal property, the rejection gate, controller propagation
incl. chase attach/restore + rejected-law aspect-still-propagates);
DisplaySettingsTests + RuntimeSettingsControllerTests updated to the new
semantics. App suite 4,953/3 skips; UI.Abstractions 916/0. AD-89 retired
in this commit; user settings.json migrated 60->90 by hand (stale
pre-port default).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Both from the 2026-08-13 display gate session. #389 carries the full
decomp-verified retail FOV law; #390 requires the retail reposition
mechanism from the decomp before any clamp is implemented.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
GameWindowSlice8BoundaryTests.FramebufferResize_IsOneTypedOwnerHandoff
correctly rejected the log line added to GameWindow.OnFramebufferResize
— the window callback is contractually a one-line handoff. The line now
lives in FramebufferResizeController.Resize after its zero-size gate,
which is also the better home (one owner, all callers covered). Full
Debug App suite 4,941/3 skips.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Three rare-event log lines so any future resize report is diagnosable
from the launch log alone: 'window: framebuffer resize event WxH',
'vulkan: swapchain recreated WxH ok=', and 'display: resolution pick
WxH (window was WxH)'. An instrumented live run on the Windows AMD box
shows the full chain firing for both the programmatic resolution apply
and external window resizes, and screen captures at 784x561 vs 1584x861
confirm fixed-pixel UI with a true pixel-count re-render.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
User report: resolution picks (and window drags) stretched the image
instead of changing the pixel count. Root cause: Campaign V slice V11
deleted the GL viewport target and left a null target, assuming the
driver's OUT_OF_DATE/SUBOPTIMAL acquire/present results would drive
swapchain recreation on resize. That is driver-dependent and
spec-insufficient — this machine's Windows AMD driver keeps presenting
the stale-extent swapchain scaled to the new window indefinitely, so
OnFramebufferResize only ever updated the camera aspect while every
pass (UI included) kept rendering at the old extent.
Fix: SwapchainRecreateViewportTarget implements the existing
IFramebufferViewportTarget seam for Vulkan and arms
VulkanGraphicsContext.RequestRecreate() on every resize event; the next
PrepareFrame rebuilds the swapchain at the live FramebufferSize (bursts
collapse to one recreation, stale events cannot install a stale extent,
minimised sizes stay gated by FramebufferResizeController).
Tests: SwapchainRecreateViewportTargetTests (target contract, size-
agnostic arming, null hook, controller-to-target end-to-end with the
minimised gate). Full Debug App suite 4,941/3 skips.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
LandblockStreamer.HandleJob's near-payload check is "fail loud in Debug
builds and strip in Release" (its own comment, with a Debug.Assert at the
check). FarLoad_StripsEnvCellsAndPhysicsEvenWhenEntityListIsAlreadyEmpty
feeds a deliberately-buggy far factory to verify the Release strip — so
under Debug the assert fires, the test host's listener turns it into an
exception, and the job publishes Failed BY DESIGN. The test asserted the
Release outcome unconditionally and therefore failed on every full Debug
App run (found 2026-08-13 during the #385 session; every campaign gate
runs Release, which is why it never surfaced). It now asserts the Failed
result + assert message under DEBUG and the strip under Release. Verified
green in both configs; full Debug App suite 4,937/3 skips.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
User gate report (Campaign OP happy-testing round, 2026-08-13): every
Config-tab dropdown drew its text gold + left-aligned and its popup a
fixed 6 rows regardless of item count. All three were unmeasured styling
divergences — the authored data (new probe menuprobe3, live DAT) says:
- button label child 0x10000355: fontColor white, hJustify=Center
- row template 0x1000035A: fontColor white, hJustify=Center
- popup ListBox 0x10000358: edge-docked L=T=R=B=1, the authored condition
arming retail UIElement_Menu::RecalculatePopupSize @0x0046caf0 —
popup resizes to the ListBox's summed content height, uncapped
(0x0046e5f4..0046e66c via ResizeScrollableArea's 0x32 broadcast)
UiMenu gains three opt-in properties (ButtonTextCentered,
ItemTextCentered, PopupSizeToContent) plus retail Open @0x0046cc42's
empty-list gate; chat + vendor keep the class defaults, so their shipped
behavior is untouched. ConfigOptionsPageController.ApplyMenuChrome wires
all four corrections for the 8 Config menus with the probe citation.
The same probe found vendor's authored popup ListBox is ALSO docked while
our vendor dropdown ships G5's fixed 6-row window — filed as #386 +
register row AD-88 (UNCLEAR: the G5 retail screenshot and the decomp
mechanism conflict) instead of silently reworking a user-gated surface.
The "resolution change resizes the window" observation from the same
report is #374's designed windowed-mode behavior (display-mode switching
is #376/#377) — no change.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The retail four-tab social panel (Fellowship & Allegiance) is
code-complete: all six slices landed and reviewed (dual-lens Opus review
-> fix round -> narrow re-review each). Fellowship two-session flow proven
live (FA6 bot gate PASSED). Closeout bookkeeping:
- register AD count 66 -> 67 (AD-87, the deferred allegiance bot gate);
- plan status flipped to CODE-COMPLETE with the OWED connected gates +
#384 (allegiance-swear ACE non-response) called out;
- CLAUDE.md Current-state gains the Campaign FA paragraph
(per feedback_claude_md_staleness), pointing at the memory digest.
Owed: the user's connected gates (§FA3-§FA6 of
docs/research/2026-08-12-campaign-fa-test-script.md) and #384's
ACE-console disambiguation. Full suite 13,304/4/0.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Plan ledger: fellowship two-session automated gate PASSED live 2026-08-12
(five of six runs reproduced the decisive cross-session assertion); the
allegiance bot gate is DEFERRED behind AllegianceGateEnabled=false pending
docs/ISSUES.md #384, with commit citations for every fix this slice landed
(confirmation relay, name-matched proximity, the fellowship-only
finalization).
Gate script §FA6: the fellowship automated-gate recipe + actual PASSED
result (the two-session config, the six proof points per stage, the
literal decisive-assertion log lines), the allegiance deferral writeup,
and a new [TWO-CLIENT] manual step (25) the user's own connected gate can
run to help disambiguate #384 (ACE-side rule vs wire-builder defect vs
harness-specific drop) using two real graphical clients instead of the
testaccount/testaccount2 pair.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
docs/ISSUES.md #384 records the live-run evidence trail (six connected
runs, the 0.005 m distance diagnostic, the confirmation-arrival diagnostic
that never fires) behind AllegianceGateEnabled=false.
docs/architecture/retail-divergence-register.md AD-87 records the honest
divergence this deferral creates: the allegiance half of the FA6 bot gate
is written and wired but unverified end-to-end over the wire, unlike the
fellowship half which is proven live.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Six live runs against local ACE (testaccount/+Acdream as Leader,
testaccount2/+Horan as Recruit) converged on a clean split:
- FELLOWSHIP two-session gate PASSES live, reproduced in three separate
runs. The decisive cross-session assertion (the Recruit bot's own
RuntimeFellowshipState — a separate process's canonical Runtime owner,
not the Leader's local echo — flipping IsInFellowship=true,
MemberCount=2, LeaderGuid=<Leader>) holds every time. This ships as the
automated gate.
- ALLEGIANCE swear never completes: ACE returns nothing at all to
Event_SwearAllegiance (0x001D) — no 0x0274 confirmation, no 0x0020 tree
update, no WeenieError — even at 0.005 m separation (run6's distance
diagnostic ruled out retail's 2.0 m swear-distance gate). Ambiguous
between an FA1 wire-builder defect, an ACE-side rule this test pair
trips, or a drop; disambiguating needs an ACE server console this
harness doesn't have. Filed as docs/ISSUES.md #384 and
docs/architecture/retail-divergence-register.md AD-87.
AllegianceGateEnabled (static readonly, not const, to avoid a CS0162
unreachable-code build error from branching on a literal) gates every
allegiance-dependent stage in BOTH policy classes off by default:
Leader's WaitForVassal (skipped straight to the reconnect+teardown that
only need fellowship state), Recruit's Swear/WaitSwornSeed/Break/
WaitBrokenSeed (same). All of that code stays fully written and wired —
flipping the flag re-enables it for a follow-up investigation once #384
closes. WaitReconnectReseed on both sides now asserts fellowship-only
re-seeding when the flag is off, preserving the reconnect-idempotence
proof independent of the allegiance blocker.
The two live-run diagnostics added while investigating #384 (the
confirmation-arrival log line in HeadlessSessionHost's
OnConfirmationRequest, and LogDistanceToPatron in the Recruit policy) are
kept as permanent, clearly-labeled evidence for whoever reopens#384 —
neither is "TEMP, strip later."
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The second live gate run exposed a real environmental hazard: this shared
ACE dev instance has a THIRD player character online (+Je, guid
0x50000001), and after @teleallto it ended up nearer to the Leader bot than
the actual Recruit bot (+Horan, 0x5000000B). RuntimeFriendlyTargetQuery.
FindClosestOtherPlayer — "nearest ANY other player" — picked +Je, and the
fellowship recruit sent to it obviously never completed (confirmed live:
WaitRecruited/WaitForRecruit both timed out, both bots quarantined and
gracefully logged out cleanly).
RuntimeFriendlyTargetQuery.FindPlayerByName resolves the nearest player
whose streamed name matches exactly, with 3 new conformance tests
(preferring the named player over a closer stranger, returning null when
absent, and case-sensitivity/hidden/no-draw/self rejection).
FellowshipAllegianceGateCoordinator (AcDream.Headless.Policies) is a small
same-process, no-locking (single update thread) carrier for the Recruit
bot's own discovered character name — set by its own HeadlessSessionHost
the instant CharacterList selection resolves it, which IS D8's "discover it
live" mechanism, not a hard-coded value. Constructed once per
HeadlessProcessHost and threaded through HeadlessBotPolicyFactory.Create
into the Leader policy, which now name-matches instead of taking whichever
player entity happens to be closest.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The first live two-bot run exposed a real gap: retail always confirms an
incoming allegiance swear to the PATRON (0x0274 Character.ConfirmationRequest,
type 1) before ACE sends 0x0020/0x01C8 to either party
(docs/research/2026-08-11-fa-allegiance-wire.md §3.3) — and unlike
fellowship's FellowshipAutoAcceptRequests (which ACE honors server-side,
never even sending a confirmation), there is no auto-accept character option
for allegiance. HeadlessSessionHost wired OnConfirmationRequest to null, so
a headless bot silently dropped every incoming confirmation and the swear
never completed — both bots timed out waiting for TotalVassals/patron to
seed, confirmed live against ACE (both quarantined cleanly with graceful
per-character logout, proving the self-terminating design and existing
graceful-shutdown path both work correctly; this was an FA6 capability gap,
not an FA1-FA5 wire/state defect).
HeadlessSessionHost now latches the single outstanding confirmation
(matching retail's own one-dialog-at-a-time shape) and exposes
PendingConfirmation/RespondToConfirmation, cleared on every reconnect since
a stale context id would be meaningless post-reconnect. The gate's Leader
policy polls and blind-accepts any pending confirmation on every tick before
its own stage switch — the v1 substitute for a human clicking Accept, safe
because the gate's two sessions are its own known bots.
HeadlessBotPolicyFactory.Create takes two new optional delegate parameters
(default null, so cannot break other policy ids); the Leader gate policy
requires them non-null via a defensive constructor check.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
two-bot gate
Adds the infrastructure docs/plans/2026-08-11-fellowship-allegiance-campaign.md
D8 and docs/research/2026-08-11-fa-acdream-seams.md §6.2 call for:
- HeadlessBotPolicyDescriptor gains an optional typed Role
(HeadlessBotPolicyRole.Leader/Recruit) so two sessions selecting the SAME
policy id run different scripts — fellowship leader/allegiance patron vs
fellowship recruit/allegiance vassal.
- HeadlessBotPolicyFactory.Create widens from Create(string id) to
Create(HeadlessBotPolicyDescriptor, GameRuntime) — the gate policies need
RuntimeFriendlyTargetQuery, which (like its RuntimeHostileTargetQuery
sibling) takes the concrete GameRuntime rather than the narrower
IGameRuntimeView a policy's own Tick receives (IRuntimeEntityView's
snapshot carries no name/PWD-bitfield). The single call site
(HeadlessSessionHost.cs) already has the constructed runtime in scope, so
no new constructor parameter or cross-session coordinator was needed.
- FellowshipAllegianceLeaderBotPolicy / FellowshipAllegianceRecruitBotPolicy:
a full stage-machine pair covering proximity (retail's admin @teleallto —
"teleport everyone online to me" — needs no cross-session name sharing,
unlike @teleto <name>; D8's proximity requirement is load-bearing, recruit
fails without it), fellowship create+recruit, the D4 0x00A6 panel-open
declaration with a vitals-presence assertion, the decisive two-session
assertions (the RECRUIT bot's own RuntimeFellowshipState/
RuntimeAllegianceState flipping — not the Leader's local echo), a
mid-flow reconnect on both bots proving FA2's reset-and-reseed semantics
over the real wire, and teardown (disband / break) with matching
decisive-clear assertions.
Every pre-FA6 policy (idle, lifecycle-smoke, observer-movement,
portal-route-smoke, jump-probe) is unaffected; the widened factory
signature is the only touch point.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
RuntimeHostileTargetQuery only classifies hostile monsters (via
CombatTargetPolicy.IsHostileMonster) — the FA6 two-bot fellowship/allegiance
headless gate needs the OTHER bot's server guid as a FRIENDLY target instead.
RuntimeFriendlyTargetQuery.FindClosestOtherPlayer mirrors the hostile query's
shape exactly (same hidden/no-draw filtering, same landblock-absolute
distance metric), substituting the retail PWD-bitfield IsPlayer bit (0x8,
via the existing EntityCollisionFlagsExt.FromPwdBitfield decoder) for hostile
classification. TryGetName resolves the streamed WeenieHeader name for
reporting/logging.
4 new conformance tests mirror RuntimeHostileTargetQueryTests's fixture
pattern: cross-landblock distance, hidden/no-draw/self/non-player rejection,
null-without-player-or-target, and unresolved-guid name lookup.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The FA5 mechanism review found the offline-vassal name-grey
(OfflineNameColor) is an invented visual: retail's UpdateVassalsData
@004924c3 writes the vassal name with no colour change, and the offline
cue is EXCLUSIVELY the authored 0x100004AA marker (already wired,
SetVisible per online state). Removed OfflineNameColor; the vassal name
always renders in the normal white. The Allegiance page now carries NO
invented tint (unlike Fellowship's registered leader/selection tints).
Pinned by Allegiance_OfflineCue_IsTheMarkerOnly_NameStaysWhite (marker
visible iff offline, name always white). AD-82's FA5 addendum corrected
(it had described the now-removed grey as 'covered by the marker'); AD-86
count corrected seven -> nine.
Full Release suite: 13,297 passed / 4 skipped / 0 failed.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
FA5 mechanism-faithfulness review of 7ed79eaf/bc29a1db/7e394cbf. Verdict
APPROVE-WITH-FIXES. Every high-stakes claim re-derived from the PDB-paired
2013 decomp: CF-1's unconditional 0x001F post-world arm (00490d59 sits
OUTSIDE the busy-count guard), the monarch/patron/self field sources
(UpdatePlayerData/UpdateMonarchData/UpdatePatronData), the SF-7
per-relationship gate, swear=world-selection/no-SetSelectedObject, and the
AD-86 ACE-zeroed-field citations all match retail.
MANDATORY live-mount probe RAN and PASSED against the real installed DATs
(1/1) — the scoped doubled-0x10000492 NotSame assertion and a full
production Bind() with zero "not found" held. FA5 unit suite 36/36 green.
One SHOULD-FIX (LOW): FA5 greys the offline vassal NAME (OfflineNameColor)
— retail's UpdateVassalsData @004924c3 sets the name with no color; the
offline cue is exclusively the authored 0x100004AA marker toggle. Either
drop OfflineNameColor or honestly register it (the AD-82 addendum's
"covered by the marker" framing understates it). Does not block the gate.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
