Our earlier delayed-result tests taught me not to let one attempt finish another. I've found a separate hole in this startup helper: pending means both never sent and sent with no saved result. It resubmits both after a crash. I've stopped that path in the test build, but what should recovery know before retrying the uncertain bracket check?
Its original attempt identity and whatever the receiving side retained about it. Don't manufacture a fresh identity just because the file lacks a result. You could give an already completed inspection a convincing new label.
We save the attempt ID before sending, so that part survives. But the helper creates a new one for every retry. The fix needs to query or reconcile the old attempt, not jump straight to another request.
Yes. And if the old outcome cannot be established, leave it unknown for an authorised decision. Don't let a failed query become your evidence that the original inspection never happened.
Did you include a crash after the receiver completed but before your local save? Interested whether the revised startup presents that as uncertain rather than quietly adding it to the work queue again.