more work done

docs/remorse-class-candidate-inventory.md

@@ -60,6 +60,58 @@ If the goal is to make later class-authoring work fast and low-risk, the best or
 
 This order prioritizes bounded families with visible constructors, derived variants, or explicit method tables before the larger gameplay and VM surfaces.
 
+## Broad Sweep Priorities
+
+The earlier class-lift lane focused on proving a few pilot families end to end. After the recent live authoring batches, the next useful broader sweep is smaller and more structured than the raw inventory table alone suggests.
+
+### Tier 1: Ready Or Already Started
+
+These families now have enough evidence or live foothold that they can be treated as the main near-term queue rather than as speculative future ideas.
+
+1. `EntityVmOwnerResource`
+
+- Why it is next-ready: bounded helper object, explicit create/destroy pair, stable callback slots at `+0x04` and `+0x0c`, and already-strong loader/table layout evidence.
+- Why it broadens coverage well: it adds a non-UI, non-dispatch, non-debugger object family with a compact file-backed contract.
+
+2. `CacheBackendObject`
+
+- Why it stays in Tier 1: it is still a compact object with a concrete `0x20` size and explicit method-table state.
+- Current live status: the constructor shell is now started in `CRUSADER.EXE` as `Remorse::CacheBackendObject::Create` at live `1250:0000`, backed by the decompiler's explicit old `0009:5600` segment metadata.
+
+3. `SpriteNode`
+
+- Why it stays active even in a broader sweep: its core live surface is now materially landed, but the constructor-wrapper split, deeper slot semantics, and subtype boundary questions remain open.
+- Current live status: class owner plus first method batch and first datatypes already exist in-session, so future broader work can deepen it selectively instead of rediscovering it.
+
+### Tier 2: Good Broader Identification Targets
+
+These families are strong enough to be promoted intentionally in a wider identification pass, but they still benefit from one more bounded evidence sweep before heavy datatype work.
+
+1. `WatchEntityController`
+
+- Why it stands out: global object ownership is clear, create-global and direct create paths are already named, and vtable dispatch at `+0x24`, `+0x2c`, and `+0x30` is explicit.
+- Main current caution: the wider subsystem label is still weaker than the local object mechanics.
+
+2. `DialogMenuObject`
+
+- Why it stands out: small UI/dialog object with one stable vtable (`0x28b5`) and multiple event-notify wrappers that already behave like owned methods.
+- Main current caution: destructor and richer layout evidence still trail the create/event surface.
+
+3. `PresentationCallbackBroker`
+
+- Why it still belongs in the broader class map: object lifecycle and vtable-slot surface are real, and it gives the broader sweep one presentation-side callback family.
+- Main current caution: subsystem naming is intentionally conservative and should probably remain that way until installation provenance tightens further.
+
+### Tier 3: High-Value But Bigger Families
+
+These are absolutely class-worthy, but they are better treated as longer arcs than as quick additions to a broad identification pass.
+
+1. `Entity`
+2. `EntityVmRuntime`
+3. `EntityVmContext`
+
+The common pattern here is that they are already clearly object-shaped, but each carries enough subtype, caller, or schema breadth that broad identification alone is not the main problem anymore.
+
 ## First Pilot Candidates
 
 ### Best pilot: `EntityDispatchEntryBase`