My FR10 tray-loading application persists the next pocket number after sending the placement request, so a stop during that request can leave the saved index ahead of the physical tray; I need a recoverable state model rather than another counter adjustment.
Track the placement attempt separately, because a pocket number tells the operator where your software wants to go but not whether the previous sleeve actually arrived.
I've added an offline attempt record with tray identity, pocket and last confirmed stage, leaving uncertain placement held for reconciliation rather than advancing or replaying on restart.
Can you distinguish an unchanged tray from one the operator replaced during the stop, because our count was once correct for the tray that had just left the station?
The current application cannot establish that automatically, so recovery now requires confirming the tray identity and physical pocket state through an agreed operator procedure; the mock tests cover a changed tray as a hold, not a continuation.
That changed-tray case is the one I hoped you'd catch, and please have a different operator try the recovery instructions before you call the handover finished.