Preserve Tier2 candidate row family evidence

This commit is contained in:
Jan Petykiewicz 2026-04-21 17:59:02 -07:00
commit 9c1fdca314
3 changed files with 50 additions and 0 deletions

View file

@ -14,8 +14,10 @@ This file is the short active queue for the current runtime and reverse-engineer
The checked `rt3_105/maps` compact-dispatch corpus is now exported directly: `41` maps scanned, `38` with dispatch-strip rows, `318` nondirect rows total, and the add-building subset is only `10` grouped occurrences across `7` descriptor keys, all still missing trigger kind. The active open question is therefore which ordinary loaded rows acquire or bypass the missing trigger-kind control lane before they can reach placed-structure mutation opcodes.
- Keep the next static Tier-2 building pass focused on the earlier seed/projection seam into `0x00412d70`, not another broad `BuildingTypes` sweep.
The grounded owner strip is `0x004196c0 -> 0x00414490 -> 0x00416ce0 -> 0x00419230`, but the active open question is which earlier seed/projection path lets the fixed candidate-table cluster at rows `35/43/45..66` reach `0x00412d70` with nonzero `[candidate+0xba/+0xbb]` before `0x00419230` clones or renames it.
Preserved checked row-family detail now lives in [Tier2 candidate row families](rehost-queue/tier2-candidate-row-families-2026-04-21.md).
## Preserved Detail
- [Archive snapshot](rehost-queue/archive-2026-04-19.md)
- [Tier2 candidate row families](rehost-queue/tier2-candidate-row-families-2026-04-21.md)
- [Progress history](history/progress-history.md)

View file

@ -4,3 +4,5 @@ This directory preserves older queue snapshots and long-form implementation note
useful as evidence, but should not stay in the short active queue file.
- `archive-2026-04-19.md`: preserved detailed queue snapshot from the pre-index cleanup.
- `tier2-candidate-row-families-2026-04-21.md`: checked candidate-table row-family split for the
active Tier-2 `0x00412d70` queue head.

View file

@ -0,0 +1,46 @@
# Tier2 Candidate Row Families (2026-04-21)
This note preserves the concrete row-family evidence behind the current Tier-2 queue head, so the
short queue can stay focused on the owner question rather than restating export details.
## Checked Export
- `artifacts/exports/rt3-1.06/candidate-table-named-runs.json`
The export now keeps the row-family split explicit instead of burying it only inside per-map
samples:
- `files_with_port01_11_run_at_45_55_count = 37`
- `files_with_warehouse01_11_run_at_56_66_count = 37`
- `port00_warehouse00_row_pair_map_counts`
- `35/43 -> 30`
- `10/18 -> 7`
- `numbered_port_warehouse_trailer_family_map_counts`
- `0x00000001 -> 28`
- `0x00000000 -> 9`
## Off-Row Carrier Maps
The earlier `10/18` family is narrow and fully enumerated in the checked export:
- `Crossing the Alps.gmp`
- `East Coast, USA.gmp`
- `Germany.gmp`
- `Go West!.gmp`
- `Rhodes Unfinished.gmp`
- `State of Germany.gmp`
- `War Effort.gmp`
Everything else in the current probe-bearing corpus keeps the `35/43` `Port00` / `Warehouse00`
pair while still preserving the fixed numbered runs at `45..55` and `56..66`.
## Immediate Reading
This keeps the Tier-2 frontier narrower than a generic “candidate table varies by scenario” claim:
- the `Port01..11` / `Warehouse01..11` numbered families are structurally fixed across all `37`
probe-bearing maps
- only the `00` pair moves, and it does so in one small `7`-map family
- the numbered trailer split is independent of the row-pair split, so the next owner question is
still the earlier seed or projection seam that feeds nonzero `[candidate+0xba/+0xbb]` into
`0x00412d70`, not the mere existence of the stable named rows themselves