When a newer commit missed deployment

A bot could look published while still running an earlier scaffold.

In AGNT GM, code generation and deployment happened independently. A build could already be running when another change merged. The deployment worker prevented two builds for the same project from running at once, but that protection had a gap: a newer redeploy request could fail to acquire the project claim and disappear.

The running build would finish successfully. It just would not contain the newest code.

Keep the pending work

I changed the worker to remember that another deployment was needed when it could not claim a busy project. Releasing the current claim could then enqueue that work again.

I also added a check after a successful deployment: if the recorded repository HEAD had moved during the build, the worker chained another deployment. Bots already running stale code were prioritized over the never-deployed backlog. Related changes stopped the early-deployment debounce from suppressing an update when HEAD had actually changed.

The distinction was between “a deployment is running” and “the latest revision has been deployed.” They are not the same state.

Check the race, not just the happy path

I added regression tests around the redeploy behavior. The important case was a newer revision arriving while the project was already claimed, rather than a second request arriving after everything had finished.

This was a focused fix to the existing deployment system: keep the concurrency limit, but do not discard the work it postpones.