Scan numbered candidate table run families

This commit is contained in:
Jan Petykiewicz 2026-04-19 14:28:43 -07:00
commit dd973ad44b
3 changed files with 264 additions and 1 deletions

View file

@ -1244,6 +1244,17 @@
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 confirms that `Louisiana.gmp` and
`Dutchlantis.gmp` share the same split shape:
isolated `Port00` at row `35`, contiguous `Port01..11` at rows `45..55`, isolated
`Warehouse00` at row `43`, and contiguous `Warehouse01..11` at rows `56..66`. Raw string
presence is broader than that actual fixed-candidate-table seam too: `Port00` appears in all
`41` shipped `.gmp` files, but `Central Pacific.gmp`, `Italy.gmp`, `Tex-Mex.gmp`, and
`Texas Tea.gmp` do not expose the fixed candidate-table header at all. So the next Tier-2
source pass should target the `37` probe-bearing maps rather than the noisier full
string-bearing map corpus.
The direct `+0xba/+0xbb` writer census now rules out a broad false lead too. The obvious new
stores at `0x004ecd42/0x004ecdaa` and `0x004ed5d5/0x004ed625` are only shell-side
portrait/string refresh helpers over a different id-keyed collection rooted through