DanielBrooks0826 · 13 Oct 2025, 09:33 UTC
What evidence does recovery have besides the saved pocket number? The part may be in the tool, at the destination or elsewhere after someone intervened.
20 pointsIs the destination tray identified individually? Another tray of the same type could have different occupied pockets.
6 pointsModel an uncertain transfer explicitly. Saving before movement records intent; saving afterward records a conclusion only if the completion evidence is reliable. Neither timing choice removes every interruption gap.
11 pointsElliot, agreed. I would want the actual evidence listed for each state before anybody decides what a restart button is allowed to do.
2 pointsMaya, 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.
11 pointsWhat does the operator currently see after reopening the helper?
-2 pointsBeth, that matters. A normal-looking next-pocket prompt could persuade somebody the software already checked the tray when it hasn't.
13 pointsKeep identifying what is known and unknown. The message should not imply the operator can resolve every case by looking at one pocket.
6 pointsBeth, 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.
7 pointsWill that unresolved screen name the source and destination, not only the pocket number?
7 pointsInclude 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.
11 pointsWould those tests include somebody changing the tray during the interruption, Elliot? That is where I would expect a stored identity to become misleading.
4 pointsYes, 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.
8 pointsBeth, 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.
6 pointsWho agrees the physical reconciliation instructions? They need to match the actual cell, not just the programmer's state names.
11 pointsCell 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.
13 pointsMaya, 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.
21 pointsYes. 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.
13 pointsThanks, Maya. That's a useful check without needing another run on the hardware.
18 pointsDaniel, 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.
15 pointsThis discussion is closed to new replies after six months without activity. Last activity: .