"Human Possible" seems to presume overly accurate tucks and spins.

The latency and Hz metric make StackRabbit very good at analyzing boards given the physical limitations of a particular human player. However, one metric is seems to be missing is the natural "misdrop" rate associated with actions that have a very small window of frames to work with. In particular, sometimes an issue occurs where on S/Z next piece, StackRabbit suggests an adjustment based on what would require a near frame-perfect tuck or spin at late levels.

I think this could be resolved by allowing us to input a mapping between how many frames of lee-way are available, and the odds of missing an input.

An example mapping could be

Window of 1 Frame: Misdrop Rate 50%
Window of 2 Frames: Misdrop Rate 20%
Window of 3 Frames: Misdrop Rate 4%
Window of 4 Frames: Misdrop Rate 1%
Window of 5 Frames: Misdrop Rate 0.5%

And of course, these numbers could be adjustable just like how latency and Hz are adjustable, since various players have various physical input skill levels.

In this method the algorithm can calculate the quality of the position Q1 assuming the place is placed correctly, and the quality of the position Q2 assuming the tuck or spin failed to execute (e.g. where the piece would go if the rotate button was never pressed, in the case of a spin, and if the left/right button were not pressed, in the case of a tuck). And then, it can calculate the EV of that move as Q1 * (1 - MisdropRate) + Q2 * MisdropRate.

This could also help apply for cliffs. At 15Hz, that's one button press every 4th frame. It takes minimum 13 frames to press the button 4 times. But, if there's a spire that requires tapping 4 times within 16 frames to clear, that leaves only a 3 frame window to miss the spire, implying that we'll hang the piece on the spire 4% of the time at Level 18.

1 0 0 0 1 0 0 0 1 0 0 0 1
     <- 
  1 0 0 0 1 0 0 0 1 0 0 0 1
   <- The three possible ways to overcome the spire at 15Hz
    1 0 0 0 1 0 0 0 1 0 0 0 1 <-
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ <- The 16-frame window to press the button 4-times within

This calculation in particular can really matter for some of its "Adjustment" recommendations, which often involves a suggestion to swing from the far left side of the board all the way to the right side of the board, barely missing the middle of the stack. Especially on higher levels, these are moves that humans wouldn't want to execute, due to the risk of hanging the piece on a spire (Or at least, the risk of the misdrop should be weighed against the quality of the board achieved by the adjustment). Avoiding these adjustments will also make StackRabbit avoid moves that depend on your future ability to make that adjustment if a "bad" piece comes.

I think including these metrics into StackRabbit would cause the "Human Possible" simulation to look far more like human play, and most importantly increase the quality of the suggestions of the "Live Trainer" by suggesting moves that weigh the risk of a misdrop. Additionally, it would likely compel the Live Trainer to create stacks that are "cleaner" with respect to avoiding dependencies on very precise moves.

No files or tests are named. Start by tracing the Human Possible simulation and Live Trainer paths described in the issue, then determine where adjustable frame-window misdrop rates and the failed-action board quality would enter the evaluation. Done means recommendations account for configurable misdrop risk when choosing adjustments and future placements.