b70b9832ff
Twelve user-provided forward items sorted into three buckets: three land on already-staged work (equipped-child picking and vendor slices are the world-interaction program's own next steps; the Settings tab is the filed V11 dev-panels follow-up), three are verification campaigns whose research already exists (property-enum divergence doc, wire-message catalog, the retail physics workflow - starting with the observed long-jump landing bounce), and six are new feature bodies for milestone sequencing (login/char creation, summoning, fellowship/allegiance tabs, in-game map, chat color/text fidelity from the cdb-captured retail values, missing slash commands). Intake ledger only; sequencing happens in the roadmap after V11 closes. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
43 lines
4.4 KiB
Markdown
43 lines
4.4 KiB
Markdown
# 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** | `docs/research/2026-06-04-property-enum-divergence.md`: 929 values missing across 7 `Property*` enums, plus the `acdream-property-enum-sweep` skill for regeneration. | Extend the sweep beyond Property* to every wire-adjacent enum family; adopt values with ACE as oracle; conformance tests per enum. |
|
||
| **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.
|