backlog-burndown "Cleanup Is the Orchestrator's" deletes an abandoned or merged group's remote branch after verifying it locally. drive-pr step 4 states the same verify-then-delete sequence in full: read the branch tip with git ls-remote --heads --exit-code, compare it to the headRefOid captured before the merge, and only then git push origin --delete.
The window between the read and the delete is unguarded. A push landing in it is deleted along with the branch, and the verification that was supposed to prevent exactly that has already passed.
drive-pr does not overlook this. It rules the remedy out explicitly: "Never --force-with-lease here, git-commit-conventions forbids it unconditionally, this plain verify-then-delete is the safety gate, not a compare-and-swap at delete time."
So the two rules meet and the residual race is what falls out. The question is a maintainer's rather than an agent's, and it is narrow: whether the fleet's unconditional force-push ban is meant to reach a delete-time expected-OID condition on a branch deletion, which pushes no commits and rewrites no history, or whether that ban is about rewriting a shared branch and a guarded delete sits outside it. If the ban stands as written, the race is accepted deliberately and both skills should say so where they state the sequence, rather than only drive-pr ruling out the mechanism without naming what remains.
Raised by coderabbitai on the develop -> main promotion pull request #1304, and deferred there under the maintainer's instruction to merge the promotion and take the findings up afterwards.
backlog-burndown"Cleanup Is the Orchestrator's" deletes an abandoned or merged group's remote branch after verifying it locally.drive-prstep 4 states the same verify-then-delete sequence in full: read the branch tip withgit ls-remote --heads --exit-code, compare it to theheadRefOidcaptured before the merge, and only thengit push origin --delete.The window between the read and the delete is unguarded. A push landing in it is deleted along with the branch, and the verification that was supposed to prevent exactly that has already passed.
drive-prdoes not overlook this. It rules the remedy out explicitly: "Never--force-with-leasehere,git-commit-conventionsforbids it unconditionally, this plain verify-then-delete is the safety gate, not a compare-and-swap at delete time."So the two rules meet and the residual race is what falls out. The question is a maintainer's rather than an agent's, and it is narrow: whether the fleet's unconditional force-push ban is meant to reach a delete-time expected-OID condition on a branch deletion, which pushes no commits and rewrites no history, or whether that ban is about rewriting a shared branch and a guarded delete sits outside it. If the ban stands as written, the race is accepted deliberately and both skills should say so where they state the sequence, rather than only
drive-prruling out the mechanism without naming what remains.Raised by coderabbitai on the develop -> main promotion pull request #1304, and deferred there under the maintainer's instruction to merge the promotion and take the findings up afterwards.