Our teaching batch has six identified housings accepted by inspection. The dashboard shows eight passes after a restart. There are nine log rows, including one failed check, so I want students to understand what is being counted instead of simply changing the displayed total to six.
In a similar count discussion the useful distinction was the item's current disposition and the attempts beneath it; do your extra pass rows identify new inspections, or repeated delivery of existing results?
Two rows carry the same attempt identities as earlier passes. They arrived after reconnect. The failed housing also has a later genuine retry with a different attempt identity. So those two kinds of repetition are mixed together.
Keep the duplicate deliveries traceable without creating additional inspection attempts, and count each housing from its authorised current disposition rather than summing successful messages.
Our coupon replay now keeps two real attempts and one accepted coupon. Re-importing the same result no longer adds an attempt. I'd include that alongside your genuine retry, because both used to look like another row arriving on our screen.
Alex, the source supplies a run identity as well as the attempt number, and we had dropped the run from our import key. The developer is keeping both. Aisha, your replay is a useful comparison for the exercise; ours needs the duplicate deliveries shown separately.
The retained example now gives seven real attempts and six accepted housings, with the two duplicate deliveries still visible. Withdrawing one acceptance gives five on screen, but Jamie was right: our export still says six. That is now a separate failing test.
The export now uses the corrected dispositions too. Tests pass for repeated import, the genuine failed-then-passed retry, withdrawal to five accepted housings, and authorised reinstatement to six. We also replayed a new run reusing attempt numbers without merging it into the old one. I've updated the exercise with those actual results.