An atomic claim stops two agents taking one ticket. It doesn't stop two tickets for one job.

The punch list comparison is spot on. “Done” and “accepted” are different events with different owners, and most trackers treat them as one status. Your estimate example also fits the overlap check well. Two trades carrying the same scope is the duplicate case. Neither one carrying it is the gap case, and a snapshot check can’t catch that one, because there’s nothing on the board to compare. That might be worth its own post.

Agreed, the gap case is the hard one. The only way I've seen it caught is comparing against a list of what should exist, not what's on the board. In estimating that list was the scope checklist for each trade. Something has to say a line is missing before anyone can notice it. I'd read that post.

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.

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.