FR5 pocket number survives the stop but disagrees with the tray

After confirmed placement. Stop between placement and save leaves the old number. No recovery state recorded.

Saving earlier just moves the uncertainty to an apparently used pocket which might still be empty; have the programmer retain the transfer stage and tray identity, then agree a recovery check for any physical result the stored state cannot establish, without automatically repeating the transfer.

Programmer added a pending transfer tied to the tray and pocket. Restart with pending work opens a recovery check. No automatic repeat. We are testing interrupted stages before releasing the job.

Include failure to save that pending state and failure to save completion, plus a different tray on restart; somebody covering the cell needs to recognise those cases without reconstructing your program.

Tests passed: failed pending save prevents dispatch; lost completion save retains pending recovery; different tray blocks continuation. Maintainer and cover operator completed the agreed physical checks without guessing the pocket. Handover accepted. Thanks for spotting the earlier-save trap.

And keep those interrupted cases with the job's checks, so a later tidy-up doesn't quietly replace recovery with loading the last pocket number again.