Linda's distinction matters even with perfect reconnect handling. Does this completion contain an acceptance decision, or merely say the inspection finished?

It means inspection finished. Acceptance is a separate result record. The application saves that record before the drop, but reconnect currently increments the displayed accepted total from the high completion alone.

Then deduplicating completion still wouldn't make that an accepted-parts count.

Exactly. Harish, can you trace the saved result to the housing and inspection attempt independently of the row currently selected on screen? Otherwise fixing the increment may leave a wrong assignment underneath it

What does the saved record say for the housing that triggered this report?

It says accepted, with a housing identity and attempt identity. The next housing is selected on screen after reconnect, which is why the repeated completion looks like progress on that one.

There are two observations to preserve then. The total increases and the current selection makes the old event appear new. I would give the developer both screenshots with the saved result, rather than only asking for a counter patch.

And include a completed inspection whose result is rejected in the replay, because this accepted example alone conceals the meaning error.

Developer is moving the total to the identified result records, not the completion callback. We have a replay with an accepted housing, a rejected housing and a repeated delivery; nothing is being resent to the cell.

Will an absent result stay unknown, rather than become rejected?

That case was added. Replay now leaves absent results pending and counts the accepted housing once. Reopening the report reconstructs the same total. The selected next housing no longer receives the old completion label.

Check a later accepted reinspection of the same previously rejected housing. It should change that housing's disposition under your quality rules, not pretend two physical housings existed. I mean the reporting test, not a request to reinspect production parts.

Quality needs to define which result governs that disposition. Latest arrival is not necessarily latest inspection after delayed delivery.

That rule is not agreed yet. I've kept the patch out of the live report until quality reviews superseded attempts; the original reconnect replay passes, but the broader accepted total is not ready.

Fair enough. Keep the old inflated report available to whoever reconciles the shift figures, labelled as the affected version. A corrected future total does not explain the totals already copied into their notes