Yes, same run and attempt identifiers. The stored row also names the same housing. Only one physical inspection occurred for that attempt.

Sounds as though reconnect has its own counting path. Does it insert another result row, increment a separate total, or both? Worth knowing which thing has actually multiplied.

Callum, it increments a separate total without adding a row. Julia, accepted housings. Will, the supervisor has the six identified housings and has marked the monitor total unreliable in the shift report.

Then can the maintainer rebuild the total from the stored housing dispositions, instead of adding one each time a completion is observed?

Luca, yes, with any superseded result handled. I don't want the oldest pass to keep a housing accepted after quality has withdrawn it. Ada, include that example when you describe the count.

And don't lose an unseen completion during reconnect. Ignore the first high bit would fix your seven by creating a different missing-six problem later.

The maintainer reproduced both cases: a known retained completion must leave six accepted housings, while an unseen completion for another accepted housing must produce seven. We added withdrawal and repeat-inspection cases.

Thanks for telling the supervisor early. Is the report rebuilt from those identified housing records now, or are they still keeping a manual correction beside the screen total?

Still using the reconciled list for reporting. The repair is in the test package, not the installed monitor. I have not asked anyone to trust the screen again yet.

Has the test package passed those cases, including being closed and reopened between saving the result and updating the display?

That reopening test caught another error. Saved dispositions were correct, but the display restored an older cached total. Developer has removed that separate source for the accepted count.

Good catch. Keep the current disposition visible for a selected housing too. The covering operator should be able to explain why that item is included or excluded without adding up its whole inspection history.

Did the cache repair survive another restart?

Yes. Duplicate retained result, unseen result, repeat inspection, withdrawn acceptance and reopening all give the expected identified-housing count. The installed reporting package is next.

When that goes in, make sure the supervisor's export comes from the same count. Our screen and spreadsheet once disagreed because only the screen had received the repair (an impressively pointless morning).

Installed monitor and export passed the controlled retained-result checks with the maintainer. Both agree with the reconciled housing list. Covering operator can find a housing's current disposition and its earlier results.

The supervisor has removed the temporary reporting workaround. Thanks, Julia, counting housings rather than every successful attempt found more than the original reconnect bug.