Add candidate table header cluster export

This commit is contained in:
Jan Petykiewicz 2026-04-21 18:41:12 -07:00
commit 0240c08012
8 changed files with 152 additions and 10 deletions

View file

@ -1244,11 +1244,15 @@
problem is no longer whether those names exist as stable scenario rows; it is how that fixed
candidate-table cluster is projected into the later aux-record bank and then into the live clone
families.
The root scan narrows the real corpus for that question too. `runtime scan-candidate-table-headers
rt3_wineprefix/drive_c/rt3/maps` shows `37` probe-bearing shipped maps and `4` skips, while the
narrower `runtime scan-candidate-table-named-runs` command now keeps those aggregates explicit
too: `port00_warehouse00_row_pair_map_counts` records the two stable `00`-row families across
those `37` probe-bearing maps as `35/43 -> 30 maps` and `10/18 -> 7 maps`, while
The root scan narrows the real corpus for that question too. The checked export
`artifacts/exports/rt3-1.06/candidate-table-header-clusters.json` now keeps the fixed header
side grounded directly: `37` probe-bearing shipped maps, `4` skips, and only `3` stable header
families across that whole corpus, namely `0x00000000 / 0x00000000 -> 27 maps`,
`0xcdcdcdcd / 0xcdcdcdcd -> 9 maps`, and `0x10000000 / 0x00009000 -> 1 map`
(`Alternate USA.gmp`). The narrower
`artifacts/exports/rt3-1.06/candidate-table-named-runs.json` export keeps the row/run aggregates
explicit too: `port00_warehouse00_row_pair_map_counts` records the two stable `00`-row families
across those `37` probe-bearing maps as `35/43 -> 30 maps` and `10/18 -> 7 maps`, while
`files_with_port01_11_run_at_45_55_count = 37` and
`files_with_warehouse01_11_run_at_56_66_count = 37` keep the `Port01..11` / `Warehouse01..11`
runs fixed at rows `45..55` and `56..66` in every probe-bearing map. Trailer families split