- Shipped
- August 26, 2026 at 8:14 PM UTC
- Author
- kamo
- Commit
- 2c28202
Two complaints about the same gesture — taking a head to the goal. **Dropping in the goal did nothing.** Scoring lived entirely inside the throw RAF loop, which only runs for heads that were flung. A head carried into the mouth and released never entered that loop, so it landed on the target and just sat there — the deliberate version of the gesture was the one that didn't work. The score-zone test and the score sequence are now shared helpers (isInsideGoalMouth, scoreHead) that both paths call, so a dropped head and a thrown head agree on what counts as "in". A drop is still put to the tool:requestClose veto, same as a throw: an unsent draft refuses, it reads as a miss, and the head drops where the user put it. **Aiming at the goal gathered the swarm.** The culprit was not the shake detector, as it appeared — it was detectHoldMoving. Its thresholds (500ms inside an 80px radius having travelled 60px, i.e. 120 px/s) describe lining up a shot, hesitating mid-drag, or simply carrying a head across the screen slowly. Measured against the old detector, all three of those gathered; a fast fling never did. So: - hold-and-stir now needs 200px of travel inside a 60px radius, and the path must end near where it began (net <= 40% of distance walked). Stirring clears that; hovering over the goal is nowhere close. - a shared veto rejects every detector when the recent path is a long, mostly straight translation — that is what a throw *is*, whatever shape it traces. - shake reversals go 3 -> 4, the segment that counts goes 6px -> 14px so tremor stops accumulating, and a reversal must double back past 120° rather than merely turn past 90°, which an arcing throw sweeps through on its own. The intentional gestures are unchanged in practice: shake, stir-a-circle and hold-and-jiggle all still fire. New **************** pins both directions. Its three regression cases fail against the previous detector and pass against this one.