The ledger the campaign owed: which oracles were actually available, what each family's end state is, what got fixed and why, and - the part that matters most for whoever picks this up - the twelve things that could not be settled from an oracle and are therefore recorded as open questions rather than guessed. Two findings deserve to survive past the morning report. The first is that five of the six vendored reference repos named in CLAUDE.md are empty directories in this environment. ACE, Chorizite, holtburger, ACViewer, AC2D and DatReaderWriter contain nothing, so the campaign re-anchored on the retail header itself - which CLAUDE.md ranks above ACE anyway - with the UtilityBelt enum catalog and the 38,985-file ACE weenie corpus as cross-checks. That turned out to be the more rigorous arrangement rather than a compromise, because of the second finding: the catalog is wrong about CraftFletchingBase, where retail and acdream agree. Trusting any single source, including the one the brief nominated, would have introduced a bug. Retail's header decided every disagreement and the weenie corpus broke ties. Also recorded: the 2026-06-04 property-enum divergence note that this work was supposed to build on does not exist - not in the tree, not under any ref, not in the memory directory, which has no research/ subfolder at all. The MEMORY.md index points at both it and a magic-number audit that is equally absent. The sweep was regenerated from scratch instead, and landed on 864 property members against the missing note's remembered 929. Someone should repoint those index entries. The Bucket B intake row is marked done and points here. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
4.6 KiB
4.6 KiB
Post-Campaign-V work intake — 2026-07-29
User-provided forward list, captured during Campaign V's V11 closeout, sorted into three buckets by what already exists for each item. This is an intake ledger, not a work order: sequencing into milestones happens in the roadmap once Campaign V closes.
A. Already planned — lands on staged work; do not double-plan
| Item | Where it already lives |
|---|---|
| Selecting wielded weapons / items players wield | Slice 4 of the active world-interaction completion program (2026-07-23-world-interaction-completion.md) — "equipped-child world picking" is the program's named resume point, paused for Campaign V. |
| Vendor management | Slices 5–6 of the same program: vendor browsing, then server-authoritative transactions. |
| Settings tab in GUI | The retained-UI dev-panels follow-up filed at V11 (ImGui Settings panel was deleted with the dev stack). Re-home onto the retained retail UI via a new IPanelRenderer; panels themselves need no rewrite. Until then keybinds fall back to keybinds.json. |
B. Verification campaigns — research already exists; work is adoption/audit
| Item | Existing foundation | Shape of the work |
|---|---|---|
VERIFY all enums — DONE 2026-07-29, see docs/research/2026-07-29-enum-verification-campaign.md |
The 2026-06-04 divergence note turned out to be missing from the repo entirely (open question 1 in the successor), so the sweep was regenerated from scratch. | Seven Property* tables created (864 members); DamageType and ItemType value bugs fixed; equipment/physics/item families closed against retail. Twelve open questions remain, headed by five empty references/ repos. |
| Verify networking stack | docs/research/2026-06-04-wire-message-catalog.md: 256 opcodes catalogued, 114 parsed. |
Audit parsed-vs-stub-vs-missing against the catalog; prioritize by what live servers actually send (Coldeve session logs are now a real corpus); holtburger remains the client-side oracle. |
| Physics review — retail landing bounce et al. | The named-retail decomp workflow; carried debt #116 (slide response), TS-50/51/53 in the divergence register. | A focused fidelity pass: start with the user's observed case — long-jump landing should bounce/recoil as retail does (grep named-retail for the landing/impact path in MovementManager/SetMotion land states before writing anything). Each fix follows grep→decompile→pseudocode→port→conformance. |
C. New feature bodies — milestone candidates, no existing spec
| Item | Notes |
|---|---|
| Login flow + character creation | Today: env-var auto-login, auto-enter first character. Retail flow = server select → account login UI → character list → creation screens (heritage/attributes/skills/appearance) → enter. Big body; touches wire (char-creation ops), retained UI, and the D.2b LayoutDesc import path. The Coldeve session proves multi-character accounts already half-work (it picked Barris). |
| Implement summoning | Post-M3 magic school: summon wire ops, pet entity lifecycle (spawn/follow/combat), CombatPet UI. Depends on enum + wire verification above for the summon-specific messages. |
| Fellowship and allegiance tabs | Two retained-UI panels + their wire surfaces (fellowship create/join/share; allegiance tree/pledges). Wire catalog marks the op families; parser status needs the B-bucket audit first. |
| In-game map button | Dereth map UI from DAT map art + player-position overlay; retail's MapView panel via LayoutDesc. |
| Chatbox cleanup — colors and text | memory/reference_retail_chat_colors.md holds exact retail RGBA values captured via cdb from live retail memory — the color half is research-done, implementation-pending. Text half: font/wrapping/timestamp fidelity vs retail. |
| Missing commands (/ah and more) | Inventory the retail slash-command surface (named-retail has the command table), diff against LiveCommandBus's registered set, implement by demand-order from the user's play. |
Suggested sequencing notes (for the roadmap discussion, not binding)
- Bucket A resumes first — it was the active program before Campaign V and two of the user's twelve items are literally its next slices.
- The B-bucket verifications de-risk everything in C (summoning, fellowship, char creation all sit on unverified wire surfaces); the enum+wire audits are also the cheapest to run as background subagent campaigns.
- C-bucket items should each get a brainstormed spec before code, per the roadmap rules; login/char-creation is the largest and most player-visible.