Agreed, and this is a real gap. Closing the old branch changes the board but doesn’t stop a runner that’s already in flight. If it delivers after the reopen and a new claim, nothing in the post stops that late delivery from landing as if it were current. Tagging each claim with an attempt ID, and accepting a delivery only when its ID matches the item’s current one, would cover it. Anything else stays attached to the old attempt for someone to look at, but never replaces the new runner’s work. I’ll add the fixture you described. “Prevents duplicate starts” and “prevents stale work from being accepted” are two separate guarantees, and the post only covers the first.

The attempt ID covers the missing ownership boundary. I would make its comparison and the acceptance write a single conditional operation, because an old runner could pass a separate check just before a new claim changes the current attempt.

That adds a useful interleaving to your fixture: pause the old delivery after reading ownership, reopen and claim the item, then resume acceptance. The old result should still be retained for inspection, while the conditional write refuses to make it current.