Documentation progress

docs/entity-dispatch-entry-class-layout.md

@@ -232,8 +232,57 @@ When manual class work starts, the safest order for this family is:
 
 Do not start by forcing one complete 0x520-byte monolithic class.
 
+## Live Ghidra Authoring Status
+
+Verified first live `EntityDispatchEntry` shell batch landed on 2026-04-07.
+
+- Created class owner `Remorse::EntityDispatchEntry` in the active `CRUSADER.EXE` database.
+- Created provisional base datatype `/Remorse/EntityDispatchEntryBase` with the current stable field block through `+0x18`:
+	- `type_or_kind`
+	- `slot_index_or_count`
+	- `source_type`
+	- `event_type_or_list_ptr_lo`
+	- `group_id_byte`
+	- `link_or_state_word_0a..10`
+	- `target_farptr`
+	- `flags1`
+	- `flags2`
+- Created provisional vtable datatype `/Remorse/EntityDispatchEntryVtable` with only the two currently verified callback slots exposed:
+	- `+0x14 = update_callback_slot14`
+	- `+0x28 = dispatch_callback_slot28`
+- Kept the remaining vtable lanes explicit as unresolved padding instead of inventing slot names too early.
+- Did not move methods yet. The current source note still anchors this family through the older `0008:` / `000d:` address notation, and those entrypoints are not yet mapped into the active live `CRUSADER.EXE` session strongly enough to justify owner moves by guesswork.
+- The current live MCP `apply_class_layout(...)` path also rejected the minimal shell bind with an undocumented required `methods` property, so this first shell pass used the now-working live `run_write_script(...)` fallback to author the class namespace and datatypes directly.
+
+This means the family is now started in-session rather than remaining note-only, but it is still in the pre-method phase.
+
+That is no longer true after the next live pass on 2026-04-07.
+
+- The older `0008:ba00` pilot cluster is now re-anchored in the live `CRUSADER.EXE` session as the `11e0:` process-substrate segment by direct offset mapping from the decompiler's embedded original-segment metadata.
+- The first strong base-method batch is now moved under `Remorse::EntityDispatchEntry`:
+	- `11e0:0000` -> `InitBase` (older note anchor `0008:ba00`)
+	- `11e0:01b6` -> `SetSourceType` (older note anchor `0008:bbb6`)
+	- `11e0:0227` -> `SetEventTypeChecked` (older note anchor `0008:bc27`)
+	- `11e0:02a8` -> `SetGroupId` (older note anchor `0008:bca8`)
+	- `11e0:0353` -> `Unlink` (older note anchor `0008:bd53`)
+	- `11e0:0405` -> `IncrementGroupId` (older note anchor `0008:be05`)
+- Those six methods now carry provisional `EntityDispatchEntryBase * this` signatures in-session plus decompiler comments recording the old `0008:` provenance so later note cleanup does not have to re-derive the mapping.
+- The current live surface is still deliberately conservative. The decompiler still shows the underlying `struct_Process` substrate in several bodies, so this batch should be treated as class ownership plus field-layout alignment, not proof that every inherited process-style helper name is final.
+- The next derived-family batch is now landed too. The older runtime-state pair from the note's `000d:` anchors is re-anchored in the live `1440:` fade/palette cluster by explicit decompiler segment metadata and matching offset delta:
+	- `1440:0000 FadeProcess_Create` -> `Remorse::EntityDispatchEntry::InitRuntimeState` (older note anchor `000d:7e00`)
+	- `1440:0278 FUN_1440_0278` -> `Remorse::EntityDispatchEntry::ReleaseRuntimeState` (older note anchor `000d:8078`)
+- Created `/Remorse/EntityDispatchEntryRuntimeState` as a provisional overlay datatype. It preserves the stable base block through `+0x18`, keeps `+0x1a..+0x3f` explicit as unresolved subtype overlay space, and names the recovered runtime-state tail fields:
+	- `+0x40 = hold_token`
+	- `+0x41 = runtime_state_flag_41`
+	- `+0x42 = runtime_state_counter_42`
+	- `+0x44 = runtime_state_delta_44`
+	- `+0x46/+0x48 = owned_buffer_a`
+	- `+0x4a/+0x4c = owned_buffer_b`
+- Those two runtime-state methods now carry provisional `EntityDispatchEntryRuntimeState * this` signatures and in-session comments tying them back to the older `000d:` evidence, which is enough to treat the runtime-state lane as class-authored rather than only documented.
+
 ## Questions To Close Later
 
+- the remaining live `CRUSADER.EXE` method mapping for the note's old `0008:` / `000d:` anchors after the first `11e0:` base-method port and the `1440:` runtime-state port, especially `entity_word_list_destroy` and the timed/periodic constructors around old `0008:cefb` / `0008:d214`
 - whether `+0x00` should be modeled as a literal `kind` field in all variants or only in some factory-built subtypes
 - exact ownership split between the base object and the embedded surfaces at `+0x1e` and `+0x28`
 - whether the seg126 startup/display subtype is truly part of the same inheritance family or only shares a lower-level dispatch-entry substrate