Receiver has a completion tied to the request identity. Our local file lacks it because storage failed after sending. Maintainer has held the old startup helper while the reconciliation path is corrected.

Test restart before submission, after submission without a result, and after a recovered result has been saved. The first may be eligible to submit; the uncertain middle case must not inherit that decision simply because both were once called pending.

What does the operator see for the uncertain one?

Currently 'pending', with the same action as unstarted work. Draft separates 'not submitted' and 'outcome unknown', showing the attempt reference and the named review route for the latter.

Have the review decision survive reopening too. Otherwise the next startup can manufacture the same uncertainty after somebody has already reconciled this housing.

And try contradictory evidence, not only a clean recovered completion. The interface needs a defined hold when two sources disagree.

Offline cases pass for unstarted, unknown, recovered completion and disagreement. Reopening retains the reconciliation and doesn't resend. The covering operator hasn't seen the new wording yet.

Let them read it without the author translating.

Covering operator distinguished not submitted from unknown and found the assigned reviewer. She thought the disagreement message meant the housing was rejected, though. We changed that to conflicting job evidence and will repeat the walkthrough before handover.

Keep the original housing's recovered completion in its own history while that lesson is revised. Fixing the restart behaviour should not erase the actual result that exposed the storage gap.