backlog: no freeze signature survives the control; boot-nav blind-tap bug found
This commit is contained in:
@@ -952,6 +952,28 @@ premise was wrong.**
|
|||||||
sequential indices); `DisableInterval` is `No` for all 111 S02 squadrons (its
|
sequential indices); `DisableInterval` is `No` for all 111 S02 squadrons (its
|
||||||
31 corpus `Yes` records are only S04 and S14, all `GNN***`);
|
31 corpus `Yes` records are only S04 and S14, all `GNN***`);
|
||||||
**`stage\EnumSquadron_Test.tbl` does not exist** — that candidate is dead.
|
**`stage\EnumSquadron_Test.tbl` does not exist** — that candidate is dead.
|
||||||
|
* 🔴 **(2026-08-25) NO freeze signature survives the control.** Six wait-object
|
||||||
|
captures across ONE healthy run: **12 thread states stable, 13 vary**
|
||||||
|
(`data/waitobj-healthy-stability.txt`). **Every** thread previously reported as
|
||||||
|
a signature is in the VARIES set — including **T68/T69**, which I had kept as
|
||||||
|
"what reproduces across both freezes": they park and unpark during ordinary
|
||||||
|
play, landing on the same objects they hold when frozen. Both frozen diffs are
|
||||||
|
consistent with healthy variation; one-sample-per-state could never separate
|
||||||
|
them. ✅ **Survives:** the 12 stable threads held the same object in all six
|
||||||
|
captures and none moved in either frozen capture, so "not a whole-emulator
|
||||||
|
stall" stands — now resting on the stable set being undisturbed rather than a
|
||||||
|
count. ⚠️ **gdb thread numbers are not comparable across runs** (this run had
|
||||||
|
T132–T142, earlier ones T104–T106) — key on object address or guest tid.
|
||||||
|
**Next: compare DISTRIBUTIONS** — N healthy vs N frozen captures, and call a
|
||||||
|
thread a signature only if its frozen distribution leaves its healthy range.
|
||||||
|
* 🐛 **(2026-08-25) Boot-nav bug found and worked around, not yet fixed.** Three
|
||||||
|
consecutive `BOOT FAILED (NO readyroom)` were **not** flakes and **not** input
|
||||||
|
loss — the d-pad and A both work (verified by moving the save cursor and
|
||||||
|
opening the dialog by hand). `wait_screen.sh readyroom 300 --tap A`
|
||||||
|
**blind-taps A**, which answers **NO** on the "Load game?" dialog, bounces back
|
||||||
|
to the save list, then reopens it — a 300 s oscillation. Driving `step up` →
|
||||||
|
`A` by hand reached the ready room in **18 s**. `launch_mission.sh` should not
|
||||||
|
pass `--tap A` while a YES/NO dialog can be on screen.
|
||||||
* ❔ **What ADVANCES a phase is still unknown** and is not in the data: swept the
|
* ❔ **What ADVANCES a phase is still unknown** and is not in the data: swept the
|
||||||
stage record and every table it names plus the `message\` family for
|
stage record and every table it names plus the `message\` family for
|
||||||
`interval|time|phase|delay|wave|spawn|arrival|trigger|start|appear|event|condition`
|
`interval|time|phase|delay|wave|spawn|arrival|trigger|start|appear|event|condition`
|
||||||
|
|||||||
Reference in New Issue
Block a user