77bc300692
poke_control.sh (self-retrying, succeeded on attempt 1 with no freeze) set the player's hull at pos+0x154 to 1. Twelve seconds later the game had put 0x447A0000 back. That establishes an asymmetry worth having: the hull word is continuously rewritten by the game, while the unit-record fields held our value untouched for 60s. It separates fields the game maintains from fields nobody writes. But it is not yet a control. The after-frame shows a red WARNING banner -- and the before-frame already shows MISSILE ALERT, so the ship was under attack in both and the banner is not attributable to the poke. A value being overwritten proves the game writes that address, not that it read ours. Correction: hull at pos+0x154 is 0x447A0000, a FLOAT 1000.0, not the 1500 the pilot logs -- those are different fields or scales and should not be conflated. The settling refinement: poke in a tight loop for several seconds so the value is low whenever the game samples it. If hull is authoritative the ship dies and the screen goes to GAME OVER; if it survives, the field is a readout. The reusable part is the harness: boot -> verify animating -> locate -> act, with a freeze at any step costing one retry rather than the iteration.