I've kept the uncertain physical housing separate from a confirmed failure in our review notes. The startup helper is less careful: it resends every entry without a saved result. One request definitely left the application before the crash. What should replace that selection rule without blocking work we genuinely never submitted?
Give confirmed unsubmitted work and uncertain attempts separate states, and make startup use those states. Renaming pending in the report won't help if the helper still selects every missing result.
I have disabled that broad selection in the test version. The uncertain attempt stays identified and held. We still need to establish which evidence permits an entry to be called unsubmitted.
Does the application save the attempt identity before trying to send it? The recovery design needs to describe failures around that save as well as around receipt of the answer.
Work from one captured case first. It may expose the bookkeeping gap without buying another logging tool. Can you connect this request to any receiver-side evidence?
Sofia, identity is saved first. Will, receiver trace confirms the same attempt was accepted, but we have not established its inspection outcome. That trace is linked to the held entry.
So don't put it back in the unsent queue. The missing outcome needs reconciliation under your agreed process, even though you now know the request was received.
Thanks for spelling out receipt versus outcome. Keep both in the test expectation; an acknowledgement should not accidentally become a completed housing in the display.
What happens if a late result arrives while the entry is held? It may add evidence without authorising a new request or deciding the physical item's disposition automatically.
The offline restart now retains the hold, identity and reason. A late result attaches to the original attempt and leaves the newer work alone. Review ownership and physical release are still awaiting the process decision.