FR10 restart offers a spacer pocket that may already be occupied

Elliot, agreed. I would want the actual evidence listed for each state before anybody decides what a restart button is allowed to do.

Maya, currently only the index and job label; Dinesh, no individual tray identity, and Elliot, our programmer is mapping the uncertain cases instead of simply moving the save earlier.

Beth, that matters. A normal-looking next-pocket prompt could persuade somebody the software already checked the tray when it hasn't.

Keep identifying what is known and unknown. The message should not imply the operator can resolve every case by looking at one pocket.

Beth, it shows the saved pocket as next; that resume option is withdrawn while we review recovery, and the proposed screen marks unresolved transfer state instead.

Will that unresolved screen name the source and destination, not only the pocket number?

Include the tool state and physical reconciliation route too. Run offline interruption tests at each action and persistence boundary, then validate the approved recovery with the cell owners before production use.

Would those tests include somebody changing the tray during the interruption, Elliot? That is where I would expect a stored identity to become misleading.

Yes, including a mismatch or unreadable identity. It must not silently inherit the old tray's occupancy. Also include a part removed from the tool before recovery begins.

Beth, both ends are named in the proposed view; Dinesh and Elliot, tray exchange and manual part removal are in the test list, with neither treated as an automatic repeat.

Who agrees the physical reconciliation instructions? They need to match the actual cell, not just the programmer's state names.

Cell owner and controls lead are agreeing them with the operator trainer; the offline model now holds the uncertain cases, but there is no approved operational recovery yet.

Maya, do you also test whether the reviewer understands why it stopped? A correct state can still leave the operator with no idea whom to call.

Yes. We ask someone outside the design meeting to explain the screen back. If they think unknown means empty, the wording has failed even if the state table is correct.

Thanks, Maya. That's a useful check without needing another run on the hardware.

Daniel, include a crash during the reconciliation save too. Recovery work can itself be interrupted, and reopening must not invent a completed decision from a half-written one.