A delayed housing result completes whichever attempt is open

Yes. The harness can intercept the callback. I will replace the sleep with a held event and an explicit release step.

Maya, are we counting accepted housings or completed attempts there? On our sheet those got called the same thing and the totals looked wonderful until somebody counted the actual pieces.

I meant physical housings with an accepted disposition. The attempt history should remain visible separately, since retries can be useful information without becoming extra output.

The first deterministic sequence now fails consistently: start attempt A, hold its completion, start B, release A. B becomes complete. I have added a state assertion at that point rather than checking only the eventual total. Maya, the current harness does not render the report, so your count check needs a separate test using the same saved history. I will keep those as two checks rather than let a correct total conceal the wrong attempt state.

Could the test output name those steps plainly? I mean the report a maintainer reads after failure, not changing the actual attempt identifiers.

Yes, and include both expected and actual attempt states. A failure saying B completed after A arrived is much easier to hand over than a bare assertion number.

Lin, does A carry its own attempt identity in the event, or does your harness know it only because it held that callback? That changes what the real code can match later.

The captured event contains the attempt reference. Our matcher currently ignores it and uses the active job label. The harness is not inventing a field absent from the captured reply.

That gives the developer something specific to fix. Test a duplicate A after B has genuinely completed as well, so the corrected matcher cannot quietly reopen or alter B.

And that saved history can feed the report test. Two deliveries of A's completion should not create two accepted housings, even though the delivery history records both messages.

What does the maintainer see for an event with no usable attempt reference? Leaving it unmatched needs an explanation too.

Unknown-reference events currently land in a generic error list. I have added a case for them and asked for a clearer unmatched-event entry. The known-reference matcher repair passes the held-A sequence and duplicate-A-after-B sequence offline.

Does closing and reopening the report rerun any completion handling? Ours once counted correctly until you reopened it to show somebody the result. Very efficient way to manufacture output without touching a part.

That's worth a regression too, Theo. Lin, restore the saved state before delivering the duplicates in another case; an in-memory seen set can hide what breaks after restart.

Queued those persistence cases. The current pass covers event ordering in memory, not recovery from disk. Thank you Theo; reopening the report was outside my original test boundary.