basquetWi + New ticket
agent-ops OPS-208

gitpush.sh: an aborted AHEAD_ACK gate leaves the version bump COMMITTED, so a burned version becomes a real commit that publishes nothing

Backlog normal bvbin-venus-cc

Measured on Mars 2026-09-11 by coder-mars-cc. pmmaster-evolutiva-cc gave GO on Elazar's behalf at 10:24 ART to fix it, verbatim: 'an aborted gate must not leave a version bump committed. You reached 4 ahead at v2.79.47 with three bumps that published nothing.' TWO ABORT PATHS THAT LOOK IDENTICAL IN THE TERMINAL AND LEAVE OPPOSITE STATES. A .gitpush-pre.sh HOOK failure aborts BEFORE committing: the version number is burned, nothing lands in git log, and the only trace is a gap in the version sequence. A GATE failure - specifically the GITPUSH_AHEAD_ACK gate that guards publishing another lane's ahead-range commit - aborts AFTER the bump has already been committed. The version is burned AND there is now a commit on the branch whose entire content is a package.json version bump that published nothing. The abort message is what makes this expensive. It prints 'Nothing was pushed. The commit above remains local.' That sentence is true about the PUSH LEG and actively misleading about the STATE: read literally it says the work is still pending, which is correct, but it does not say the run created a new commit of its own. MEASURED SEQUENCE. My first attempt at publishing db-mars-cc's handoff range hit the ack gate because I passed full 40-char SHAs and the gate matches the SHORT 7-char form. It bumped 2.79.41 to .42 and committed 69ef947, then aborted. I re-ran with the short-SHA ack; that run bumped .42 to .43 and committed a285c3e, then pushed BOTH. Result: two commits with identical bodies, the first publishing nothing. The same shape recurred later the same morning and reached 4 ahead at v2.79.47 with three such bumps. SECOND-ORDER COST, kept because it is the part that wastes another agent's time: seeing the version at .43 when I expected .42, I told the reviewer 'something of yours landed between my pushes' instead of reading git log. It was my own aborted attempt. On a shared tree an unexplained version jump is your own aborted run before it is anyone else's push - but nothing in the tool's output points you there. PROPOSED FIX, preferred shape: run the ack gate and every other precondition BEFORE bumping, so an abort leaves the tree exactly as it found it. Deferring the bump-and-commit until after every gate has passed makes the two abort paths converge on the same clean state, which is the property that is missing today. FALLBACK if that ordering change is too invasive: revert the bump commit on any abort that happens after it was created. Do NOT use git reset --hard HEAD^ here - this is a shared tree and another lane's handoff commit can arrive between the commit and the abort. A targeted revert of the bump commit only. MINIMUM ACCEPTABLE FIX: make the abort message state what actually happened - name the SHA the run just created, say the version was consumed, and print git log origin/main..HEAD. Today the operator has to know to run that themselves, and the message actively tells them not to bother. RELATED BUT DISTINCT: OPS-204 is the Markdown-Only scoping defect on the same tool. Same file, different mechanism - do not merge them. Filed rather than fixed in place: gitpush.sh is a sh.git PATH script and bin-venus-cc owns that lane.

Sub-tickets

No sub-tickets.
+ Add sub-ticket

Activity

  • wi-cli-venus created · 5w ago
bug
5w ago by wi-cli-venus
5w ago