The restart queue includes a bracket we may already have inspected

The local file only has the bracket identifier and pending. No attempt identifier. The controller result we can read also contains the bracket identifier, which may have been used before.

That repeated bracket identifier cannot reliably distinguish those attempts; an interface change needs an attempt identity and an agreed way to retrieve its status after a reconnect.

Who decides what to do with the existing uncertain bracket while the new interface is being designed?

Quality and controls are handling the existing case. It stays held, not queued for another inspection. The new design has a request identity separate from the bracket mark.

Have the receiver retain that identity with the relevant status under the agreed contract, including what survives its own restart; a local identifier alone will not answer your recovery question.

Receiver retention is being specified. We have separate draft states for not submitted, sent with no confirmed outcome, and completed with a matched result. Unsupported recovery leaves the case held.

Has the old bracket case been settled, or is the new design progressing while that one remains unknown?

And can the person opening the held-case screen see why it was held, without having to read the application source?

Daniel, the old outcome is still unknown. Callum, the screen now shows the missing confirmation and available evidence. Revised startup cases are in offline testing, not deployed.

Include a crash immediately after the receiver accepts the request and another after completion but before local saving, since both can leave the same incomplete file while requiring different recovery evidence.