232550595d
Run 1 falsified P3 as written -- the walk is NOT ascending element address, 0 of 5 sequences -- and handed back a sharper key: it is lexicographically ascending in (fleet->Location*, fleet*), 5 of 5. Both are heap addresses. Run 1 also found something the static read had missed: the newly minted fleet ids are ALREADY on the fleet objects when the assignment walk claims them, so the id-to-group pairing is decided upstream of AssignFleetsAndIssueOrders. The cross-process test that separates 'the Location pointer is the key' from 'the Location pointer is a correlate' is committed here, while run 2 was still loading and before its autosave existed. |
||
|---|---|---|
| .. | ||
| control-flow | ||
| objects | ||
| resolutions | ||
| subsystems | ||
| .keep.md | ||
| 00-strategy.md | ||
| 01-fingerprint.md | ||
| _template.md | ||