The automatic startup helper is disabled for this investigation. I have retained the pending file and the available logs.

Good. I'd split never submitted from may have been submitted in the draft, but don't let renamed labels imply that the old records contain evidence they never saved.

And plan a test for the crash between sending and recording that send. Otherwise the new submitted flag can leave exactly the same uncertainty under a more impressive name.

The receiver log uses our job label, which can be reused. No durable attempt identity links this pending row to a unique result.

Then leave this historical outcome unresolved unless other evidence distinguishes it. For future work, the request identity needs to survive retries and restarts, with receiver behaviour defined for repeated delivery of the same attempt

Julia, yes, but I would not make the operator learn the protocol to understand the screen. They need to see which plate attempt is uncertain and who reviews it, without a tempting button that means try again blindly.

Will the uncertain entry stay outside both the completed total and the automatic work queue?

It should remain visible without being counted as completed or treated as unsent. Hiding the row would make the totals tidier by removing the unresolved work from sight.

That's the draft behaviour. Uncertain stays visible for review, outside both groups. I haven't reclassified the old pending entries based only on their label.

Who owns that review, Leah? The startup change prevents a blind resend, but someone still needs responsibility for reconciling the evidence or deciding the next authorised action

Controls and quality are named in the draft, with quality owning the plate's disposition. No one has assigned a result to this old attempt.

For the offline test, put the crash after receiver completion but before the local save as well as before submission. Those cases should produce different evidence, not just the same pending row with different timing.

And reopen during the review itself. An uncertain entry must not quietly return to the runnable list because the reviewer closed the application.

Those cases are in the test plan, including reopening mid-review. The startup helper remains disabled; the revised state handling is not yet tested, and this historical inspection stays unresolved.