Review catch. The previous commit checked the counter after
find_abs_node_pos, which is still too late.
The anti-stuck block sits BEFORE the scan in the loop body:
790 if _heading_rejects >= MAX: abort <- top-of-loop check
799 if not did_force_move and now - last_move > 3.1:
808 char.move(...) <- the wall-driving guess
826 node_pos_abs = self.find_abs_node_pos(...) <- 3rd rejection recorded
833 if _heading_rejects >= MAX: abort <- too late
With two rejections banked, the moment 3.1s elapses the anti-stuck block
force-moves along last_direction — driving a wall-wedged character further in —
before the third rejection has been recorded. The exact guess this guard exists
to prevent stayed reachable on the threshold iteration.
The scan and the abort decision now both run ahead of the anti-stuck block, so
the counter is current when that decision is made.
The ordering test could not catch this: it searched for "taking a random guess"
only in the source AFTER find_abs_node_pos, while the guess block sits before
that call, so the comparison was against nothing. It now locates the anti-stuck
block explicitly and asserts BOTH the scan and the abort precede it.
Verified by falsification: restoring the scan-after-guess order fails with
"the node scan must run BEFORE the anti-stuck force-move".
That is now four times in this codebase where a check was verified by where it
sat in the source rather than by whether it ran at the deciding moment.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
1c19b8bdc8