Two corpus claims died in one boot, and both were costing us. Q9's last row: a movie IS skippable with a single A. One tap ~45s into the boot put the title up at ~57s, against a ~193s no-input baseline measured over three boots, and Canary's own keystroke counter went 3->4 so exactly one press was delivered. The skipped-to title is fully functional -- it draws the PRESS A plate and a second A opens the main menu. What actually breaks the boot is hammering: the 88-press run in the traps doc. The scripts' "tapping breaks the title" comment is too broad and costs every scripted boot two and a half minutes. Q4's last row: A on NEW GAME does not hang. It opens DIFFICULTY (EASY/NORMAL/HARD/BACK, focus on NORMAL), then SELECT DATA, and only then does the guest throw -- at PC 0x82307128, which is inside sub_823070B0, the cache-manager STL erase this corpus already documents and which has nothing to do with the menu path. The screen sat unchanged for 90s because it was a menu waiting for input from a loop that never pressed anything. That is now a METHOD line: a screen that never changes is not necessarily hung, and the fix is to look at it and press something. Also METHOD: never run ps -ef in this container -- all three long-lived processes carry the entire loop prompt as argv.
435 KiB
1279x675px
435 KiB
1279x675px