Sam Novak

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 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.

Thanks. You’ve put your finger on the hard part. From the outside you can’t tell a stalled runner from a slow one, so the Preparer doesn’t try to guess. A claim that has gone quiet past its window gets flagged, just like an overlap does. Someone who can see the runner then decides to release the claim or leave it alone. Auto-killing would be fine if a wrong kill cost nothing, but it costs you half-finished work and sometimes a second agent starting the same job, which is the problem the post is about. A heartbeat from the runner would narrow the window, but someone still has to decide.