Crusader_Decomp/docs/remorse-class-lift-index.md

Remorse Class-Lift Work Index

Purpose

This note is the easy-to-find landing page for the current Remorse C++ and class-lifting preparation work.

Use it as the starting point when the project returns to:

• class and namespace authoring inside Ghidra
• vtable and instance-layout promotion
• hand-maintained C++ skeleton emission
• ABI-safe source reconstruction planning

This index does not replace the detailed notes. It groups them into one work order so later implementation can resume quickly.

Read This First

1. docs/remorse-cpp-decompilation-plan.md
2. docs/remorse-class-candidate-inventory.md
3. docs/remorse-rebuild-abi-notes.md
4. docs/ghidra-mcp-class-lifting-endpoint-spec.md

That set gives the high-level target, the current candidate families, the rebuild constraints, and the future MCP authoring surface.

Current Note Groups

1. Overall Direction

• docs/remorse-cpp-decompilation-plan.md: staged route from decompiler-style C toward evidence-backed C++.
• docs/remorse-rebuild-abi-notes.md: Track A versus Track B guardrails, segmented-pointer concerns, packing, and calling-convention constraints.
• docs/remorse-toolchain-fingerprint-evidence.md: focused evidence note for the bound NE/Phar Lap/High-C-related toolchain story that underlies the ABI constraints.
• docs/remorse-cpp-compatibility-header-draft.md: first draft of the compatibility/support layer that future C++ skeletons should target.

2. Candidate Inventory And Tooling Surface

• docs/remorse-class-candidate-inventory.md: strongest current class candidates and modeling order.
• docs/ghidra-mcp-class-lifting-endpoint-spec.md: missing class/vtable/datatype authoring operations for the local MCP fork.

3. Family-Specific Layout Notes

• docs/entity-dispatch-entry-class-layout.md: current EntityDispatchEntry base-versus-derived model, release surface, and subtype overlays.
• docs/sprite-node-class-layout.md: SpriteNode destructor/event surface and candidate virtual-slot map.
• docs/entity-class-family-split.md: conservative split of the large Entity lane into base, projectile, debris, corpse/actor, and adjacent non-entity families.
• docs/entity-vm-runtime-owner-resource-layout.md: current runtime/helper/context ownership model for the VM lane.
• docs/presentation-callback-broker-layout.md: current object/lifecycle/vtable evidence for the 0x4588 presentation-state callback broker family.

4. Execution Checklists

• docs/remorse-first-class-authoring-checklist.md: concrete first-batch checklist for the initial Ghidra/MCP class-authoring pass, with pilot-family guidance and source-emission gates.

Recommended Work Order

Stage 1: Keep The Evidence Model Honest

1. Re-read the plan, ABI note, and candidate inventory.
2. Pick one family with bounded ambiguity.
3. Confirm ctor, dtor, vtable root, and stable field groups before any class ownership changes in Ghidra.

Best current pilot families:

1. EntityDispatchEntry
2. SpriteNode
3. EntityVmOwnerResource

Entity remains a top-priority family, but it should be split deliberately rather than promoted as one giant class too early.

Stage 2: Ghidra Authoring Pass

1. Create class or namespace owners.
2. Move only strongly owned methods first.
3. Create provisional instance structs and vtable structs.
4. Preserve slot order and unresolved fields instead of trying to beautify them.

The future MCP endpoint sequence should follow the spec note rather than ad hoc scripting.

Stage 3: First C++ Skeleton Slice

1. Emit one header/source pair for the pilot family.
2. Build it against the compatibility layer rather than raw host C++ alone.
3. Keep unresolved offsets as named placeholders instead of collapsing them into speculative semantics.
4. Record which parts are Track A safe versus Track B convenience-only.

Immediate Follow-Ups Still Open

1. Convert the first family note into a hand-maintained C++ skeleton once the compatibility header is accepted.
2. Implement the MCP class/vtable authoring endpoints only after the workflow and note set above are stable enough to drive them.
3. Add one more dedicated note for the callback/object lane around 0x4588 only if later caller evidence supports a stronger subsystem name than PresentationCallbackBroker.
4. Turn the first-class-authoring checklist into a completed execution log once the first real MCP batch lands.

Bottom Line

The current prep work is now large enough that it should be treated as one coordinated lane rather than scattered notes.

Use this file as the resume point for future class-lift and C++ reconstruction work.