code/inventory/SCANNER-API.md

@@ -229,11 +229,20 @@ The correct C approach uses the standard OO API (the same one the SDK's
 
 These C wrappers sit over `LIBMANAGER` (create/handle) and `MESSMANAGER` (send).
 
-**Next RE target (well-defined):** extract from `SCANNER.DYL` in the ROM its
+**Next RE target (well-defined):** extract from `SCANNER.DYL` its **category id**
-**category id**, **class**, and the **message ordinals** (`O_...`) for
+(candidate token in ROM: **`oscanner`**), **class**, and the **message ordinals**
-init / set-params / trigger / read, plus their parameter structs. With those, a C
+(`O_...`) for init / set-params / trigger / read, plus their parameter structs.
-client can create the scanner object and message it — the documented OO way.
+OLIB assigns ordinals dynamically from the whole class hierarchy (base classes in
-Validation still requires the physical device (MAME cannot inject a scan).
+`olib`/`hwim`), so they resolve at runtime rather than in a static dump — capture
+them with the **SIBO Debugger**, which supports remote debugging (PC↔device over
+serial) and **breakpoints inside dynamic libraries**. With those, a C client can
+create the scanner object and message it. Validation requires the physical device
+(MAME cannot inject a scan).
+
+**See [`CONTINUATION.md`](CONTINUATION.md)** for the full on-device debugging
+procedure (capture the category/ordinals/params via `LIBMANAGER`/`MESSMANAGER`
+breakpoints), a C test-harness template, and how to turn the captures into the
+shipped reader.
 
 To close it, one of:
 1. The **Workabout MX C SDK** `SCANNER.DYL` header / OO category definition (what