Record dispatch cluster corpus totals

This commit is contained in:
Jan Petykiewicz 2026-04-19 10:03:12 -07:00
commit 965bcf10c7
2 changed files with 11 additions and 0 deletions

View file

@ -5463,6 +5463,10 @@ fn build_periodic_company_service_trace_report(
"The periodic-company trace now also surfaces the strongest non-transport persisted source candidate for [site+0x276]: the ordinary loaded runtime-effect lane 0x00444d92 -> 0x00432f40(kind 8) -> 0x004323a0 -> 0x00431b20 above the non-direct 0x4e99/0x4e9a/0x4e9b bundle. That branch is no longer just a blocker note; the remaining question is the tighter control-lane mapping from loaded rows into trigger kind 8 and then into the placed-structure mutation opcodes."
.to_string(),
);
notes.push(
"Installed-map cluster counts now sharpen that candidate lane too: the current rt3_105/maps corpus has 41 bundled maps, 38 of them with dispatch-strip rows, and 318 dispatch-strip records total, all still on the non-direct compact family with null trigger kind. The add-building subset inside that corpus is narrower still at 10 grouped occurrences across 7 recovered descriptor keys (Barracks, Bauxite Mine, FarmGrain, Furniture Factory, Logging Camp, Port01, Warehouse05), again all with null trigger kind. So the open question is no longer whether ordinary loaded rows can reach the 0x00431b20 strip at scale; it is specifically how any of those rows acquire or bypass the missing trigger-kind control lane."
.to_string(),
);
notes.push(
"Direct local binary inspection now grounds the cached-candidate restore bridge too: the placed-structure stream-load owner 0x00413280 dispatches per-entry vtable slot +0x40 on the 0x005c8c50 specialization table, that slot resolves to 0x0040ce60, and 0x0040ce60 immediately re-enters 0x0040cd70 plus 0x0045c150. So the acquisition-side cached source/candidate bridge [site+0x3cc/+0x3d0] is no longer a generic restore mystery for stream-loaded rows; the remaining restored-row gaps are [site+0x276] and the deferred tri-lane.".to_string(),
);