acdream/docs/plans/2026-07-29-post-vulkan-work-intake.md
Erik c19680fd69 docs(enums): the 2026-07-29 verification campaign, end to end
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>
2026-07-29 01:33:50 +02:00

4.6 KiB
Raw Blame History

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 56 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 enumsDONE 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)

  1. 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.
  2. 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.
  3. 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.