erik/acdream
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 2

plan: Campaign FA — the retail social panel (Fellowship & Allegiance)

Browse source 
Seven slices over the four committed research lanes + the U2 slot-table
closure: Core.Net truth (repair/complete/delete the H.2 scaffolding),
two sibling J-owners with different lifetimes, the OP3-recipe mount of
the ONE four-tab social panel (id 12: Friends/Allegiance/Fellowship/
Squelch), the two live pages, bot-vs-ACE gates (second ACE account is
the user prerequisite at FA6), and closeout. Nine design decisions
stated (D1-D9); Campaign OP's gate lessons imported as binding rules.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Erik 2026-08-11 23:44:21 +02:00
parent 1226f289f3
commit bb48d2c89d
1 changed files with 187 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

187
docs/plans/2026-08-11-fellowship-allegiance-campaign.md Normal file
View file

@ -0,0 +1,187 @@
# Campaign FA — the retail social panel: Fellowship & Allegiance
> **For agentic workers:** slices are executed by ONE Sonnet implementer at a
> time against this contract, then dual-lens Opus-reviewed, per §7/§8. The
> four research docs in §1 are the spec's data appendix — implementers MUST
> read the cited sections before coding; every table this plan references is
> committed there in full.
**Status: ACTIVE — planned 2026-08-11. No slices landed yet.**
**Goal:** retail's social panel — the four-tab `gmPanelUI` member at host
slot `0x1000018F` (panel id **12**): **Friends / Allegiance / Fellowship /
Squelch** — with the Fellowship and Allegiance pages fully live
retail-faithful end-to-end (authored LayoutDescs, real wire, Runtime-owned
state, live consumers), the Friends and Squelch pages bound read-only to
the state Runtime already owns, and automated bot-vs-ACE gates for the
two-session flows. Campaign directive: the 2026-08-11 /goal (Campaign FA).
**Architecture:** one panel mounted exactly like Campaign OP's Options
panel (the OP3 recipe: `LayoutImporter.ImportInfos(dats, 0x2100006E,
0x1000018F)`, Type-8 tab host + `ActivateTabBehavior`, per-page scoped
controllers, `RetailPanelCatalog` id 12, F3/F4 keybinds). Fellowship and
allegiance state live in TWO new sibling Runtime owners under
`GameRuntime` per the Slice-J pattern (different lifetimes: fellowship is
session-scoped; allegiance survives reconnect behind a seed latch). Wire
parsers/builders live in `AcDream.Core.Net` beside the H.2 scaffolding
they connect, repair, or replace. Both graphical and headless hosts are
served by the single inbound wiring site.
---
## 1. Research base (committed; the spec's data appendix)
| Doc | What it pins |
|---|---|
| `docs/research/2026-08-11-fa-panel-structure.md` (lane A + coordinator addendum §10) | The social-panel mount (slot `0x1000018F`, id 12, four pages with `RegisterElementClass` identities), both element inventories, the row-template mechanism, the five confirmation dialogs, empty states, F3/F4 open path, the 16-slot host table, unknowns U3–U10 |
| `docs/research/2026-08-11-fa-fellowship-wire.md` (lane B) | 31-feature master table; per-message field order (golden-vector source); the byte-decoded `IsFull >= 9` and the x87 XP-share table (1.0…0.28, 2.8× cap); four pinned ACE divergences (share `.3`, 900 s vs 600 s lock, dual `shareLoot` encodings, zeroed cp/lum); the two latent acdream builder defects; the `0x00A6`-gates-vitals prerequisite; accept/decline = the shared confirmation triple (type 4); dead `0x01C9`/`0x01CA`; 8 missing WeenieError strings |
| `docs/research/2026-08-11-fa-allegiance-wire.md` (lane C) | 27 C→S + 5 S→C binary-verified messages; `AllegianceProfile`/`AllegianceHierarchy` layout with ELEVEN version gates; tree-assembly rules (orphan record ⇒ whole-message discard; sibling order REVERSES); ACE's deliberately-zeroed profile fields; the reuse verdict on `ParseAllegianceInfoResponse` and the DELETE verdict on `Core/Allegiance/AllegianceTree.cs`; the retail-faithful permanent dimming of the two allegiance notification bits |
| `docs/research/2026-08-11-fa-acdream-seams.md` (lane D) | The H.2 scaffolding inventory (11 event ids, 5 fellowship builders, swear/break, LogTextTypes, F3/F4 actions — all unreachable); the two-sibling-J-owner recommendation with the 8-edit template; the ONE inbound registration site; the six dimmed rows + their pinning tests; the panel-mount template; bot-gate requirements (second ACE account, role-discriminated policy, 7 commands, 7 assertions); `0x027C` already has a handler to share |
## 2. Design decisions (stated per the campaign directive; reactable at gates)
- **D1 — one social panel, all four tabs ship.** The DAT authors ONE
four-page panel; mounting only two pages would be an invented divergence.
Fellowship + Allegiance pages are this campaign's core (fully live).
Friends + Squelch pages bind READ-ONLY to `RuntimeCommunicationState`'s
existing friends/squelch owners (J4.1) for display; their mutation
actions (add/remove friend, squelch edit) are wired only if their wire
is already served by ACE and trivially pinned in-slice — otherwise the
action buttons are honest INERT with register rows (the OP3 precedent),
completed post-campaign.
- **D2 — two sibling Runtime owners.** `RuntimeFellowshipState`
(session-scoped, cleared at reset like external-container) and
`RuntimeAllegianceState` (survives reconnect behind a `HasServerSeed`-
style latch). Lane D's 8-edit template per owner; consumers poll via
`Snapshot.Revision` — no `IRuntimeEventObserver` member is added (that
would break all five bot policies + the trace recorder).
- **D3 — the H.2 scaffolding is connected, repaired, or deleted — never
trusted.** Connect: the 11 `GameEventType` ids, `AllegianceRequests`
swear/break, both `LogTextType`s, F3/F4 actions. REPAIR: the fellowship
builders (lane B: `BuildFellowshipCreate` invents an `openness` field
ACE silently misreads as inverted `shareXP`; `BuildFellowshipUpdate`
mislabels `0x00A6`; the real openness action `0x0291` and leader-quit
`0x0290` are missing) with their wrong-shape tests re-pinned to the
verified field order. DELETE: `Core/Allegiance/AllegianceTree.cs` + its
tests (passup formula ~1000× wrong and locked in by test; tree model
contradicts the wire). REUSE: `ClientCommandResponses.
ParseAllegianceInfoResponse` extended with the eleven version gates —
no second profile parser.
- **D4 — `0x00A6` (panel-open declaration) is wired to real panel
visibility.** ACE streams fellow vitals ONLY while the panel is
declared open; without it the roster freezes at join. Sent on the
fellowship page's show/hide through the page-visibility seam OP3
already exposes.
- **D5 — parse defensively where ACE is internally inconsistent; display
retail's own numbers.** `shareLoot` is read as raw uint `!= 0` (ACE
encodes it two incompatible ways). The XP-share percentage column uses
retail's byte-decoded table (1.0/.75/.6/.55/.5/.45/.4/.35/.3111111/.28,
default 0.0) — one register row records the knowing display divergence
vs ACE's `.3`-at-nine-fellows server math.
- **D6 — confirmations ride the existing dialog seam.** Swear/accept-
swear/break/kick/fellow-invite are plain Confirmation dialogs
(`0x0274`/`0x0275`/`0x0276`, type 1 = allegiance, 4 = fellowship);
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` /
`FellowshipAutoAcceptRequests` (auto-decline / auto-accept before the
dialog), giving those two dimmed rows their real consumers.
- **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
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.
- **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.
- **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).
## 3. Slice map
Dependencies: FA1 → FA2 → (FA3 → FA4/FA5) and FA2 → FA6; FA6 also needs
FA4 (recruit) + FA5 (swear). FA7 closes. Default execution order: FA1,
FA2, FA3, FA4, FA5, FA6, FA7.
| Slice | Contract (summary) | Gate |
|---|---|---|
| FA1 | Core.Net truth: repair fellowship builders + re-pin golden vectors; add `0x0290`/`0x0291`/`0x00A6`; the allegiance action set the panel needs (swear/break/kick/info at minimum; the rest of the 27 as builders only where ACE serves them); parsers for the 11 S→C events incl. the profile version gates (extending `ParseAllegianceInfoResponse`) and the tree discard/reversal rules; complete the confirmation triple; add the 8 WeenieError strings; DELETE `AllegianceTree` | automated only |
| FA2 | `RuntimeFellowshipState` + `RuntimeAllegianceState` (lane D's 8-edit template each); single-site inbound wiring serving BOTH hosts; typed commands/views; snapshot revisions; reset/reconnect semantics (session-scoped vs seed-latched); bot event surface via polling | automated only |
| FA3 | The social panel shell: mount slot `0x1000018F` (catalog id 12), F3/F4 handlers, fixture dump of the slot (closes U3/U4/U6/U7/U10), tab activation, all four pages' empty states, Friends/Squelch read-only binding to J4.1 state | user (connected) |
| FA4 | Fellowship page live: roster rows (adds `UiTemplateListBox` Flush/selection/row-instance-id — lane A sized this), the `0x00A6` show/hide declaration + vitals stream, create dialog (inline name field, shareXP), recruit/dismiss/quit/disband/leader + confirmations, share display per D5, option-row un-dims per D7 | user (connected) + bot |
| FA5 | Allegiance page live: profile parse on show (`0x027B`), monarch/patron/self blocks, flat vassal list with the reversal rule honored, swear/break/kick + confirmations, ACE zeroed-field presentation scoped honestly (register row) | user (connected) + bot |
| FA6 | Bot-vs-ACE automated gates: second-account config (USER PREREQUISITE), role-discriminated policy, the 7 Runtime commands + 7 named assertions (decisive: the recruited/sworn bot's own snapshot flips), reconnect-idempotence | automated + bot-vs-ACE run |
| FA7 | Closeout: register reconciliation, ISSUES sweep, CLAUDE.md Current-state paragraph, memory digest, the connected-gate test script (the campaign's stop condition) | user's final connected matrix |
## 4. What is explicitly OUT of scope
- Friends/Squelch mutation wire beyond D1's trivially-pinnable bar
(post-campaign completion; register rows).
- Allegiance officer/MOTD/banlist management UI — ACE zeroes or ignores
most of it (lane C §ACE-caveats); builders may exist from FA1 but no
panel surface beyond what the authored layout carries.
- XP passup FORMULAS client-side — `_cp_tithed` arrives pre-computed; the
deleted `AllegianceTree` transcription is not replaced.
- The `0x01C9`/`0x01CA` dead opcodes (COMDAT-folded no-ops in retail).
## 5. Verification discipline
Per commit: `dotnet build -c Release` + FULL Release suite green
(baseline at plan time: 13,103 / 4 skips / 0 failures at `28bef4e0`+the
gate-4 fixes). Golden byte vectors for every wire builder against the
lane-B/C field-order sections. Conformance pins for every panel
inventory and the tab table. The live-DAT probe harness
(`ACDREAM_PROBE_LIVE_MOUNT=1`) extended per slice — fixture-green alone
is NOT acceptance for anything mounted (the #372/#375/#378 lesson).
Register rows in the same commit as the deviation. No user-visible
invented English ever.
## 6. Campaign OP lessons imported as binding rules
From `claude-memory/project_settings_options_digest.md`'s DO-NOT-RETRY
table and the gate rounds: pass the string resolver to EVERY
`LayoutImporter.Build`; same-layout template-list prototypes are skipped
by the importer (verify for this layout's templates); activate the Type-8
host or pages stack; seed lazily-created fill-anchored children with
their parent extent; scoped `FindDescendant` for every id that repeats
across pages (lane A: `0x10000492` twice INSIDE the allegiance page);
popups get pointer priority via the UiRoot popup registration; straddling
rows clip (never whole-cull); BN literal-0 operands are byte-verified
before use.
## 7. Review protocol
Dual-lens Opus review per slice (mechanism-faithfulness ×
regression/blast-radius), fixes applied by the implementer; REJECT →
focused re-review; TWO failures → Fable fixes directly. Findings
persisted to a committed doc BEFORE any fixer/re-reviewer dispatch.
## 8. Process rules (binding, inherited from Campaign OP)
Max 3–4 agents in parallel INCLUDING children; every agent prompt
carries an explicit no-subagent clause; ONE builder/tester on the tree
at a time (read-only research may overlap); agents never launch the
graphical client (headless bot-vs-ACE runs are allowed); the user runs
connected gates; ledger placeholders anchored per-row; decomp claims
byte-verified against the PDB-paired binary; stalled agents resumed via
SendMessage before any redo; agent claims spot-verified at the seams
before anything builds on them.
## 9. Ledger
| Slice | Status | Commit(s) | Review | Gate |
|---|---|---|---|---|
| FA1 | — | | | |
| FA2 | — | | | |
| FA3 | — | | | |
| FA4 | — | | | |
| FA5 | — | | | |
| FA6 | — | | | |
| FA7 | — | | | |