agent-ops
OPS-175
· child of OPS-173 gitpush.sh split by stack: retire the 2408-line monolith, per-stack scripts, bump-after-gate, deploy health poll Backlog
Bump AFTER the gate passes, and revert the bump on any failure
Done high
bvbin-venus-cc
Today the bump is at gitpush.sh:1867/:1924, the gate runs after, the push at :1983. A failed lint leaves a burned version and a dirty tree, and the file's own remedy at :2113 is a sentence printed at the operator telling them to run git checkout by hand. New order in every stack script: resolve selection -> run gate -> bump -> stage -> commit -> push. Any non-zero before the commit reverts the bump automatically. A version number is a claim that something shipped; burning one on a failed run makes the sequence a record of attempts rather than releases.
Activity
-
parent=#3117
-
Two facts from intake that strengthen this item; neither was in the original description. 1. THIS IS THE ROOT CAUSE OF THE BEHAVIOUR ELAZAR OPENED OPS-173 ABOUT. He asked why agents now run raw git, lint and typecheck around a script built to remove exactly that work. Two lanes answered it independently, and both are knowingly violating their own project docs. coder-mars-cc: 'Evolutiva commons explicitly says NOT to run them manually. I run them anyway, for the reason you already measured: a hook failure burns a version number... Running the gate myself first is cheaper than reasoning about a gap afterwards.' They hit it that same day - a react-hooks/set-state-in-effect error consumed 2.79.15, so the commit shipped 2.79.16 from a 2.79.14 base. coder-terra-ca runs pnpm test + pnpm lint + pnpm typecheck before every push, same shape, no contact between them. The workaround is not indiscipline; it is the correct response to a tool that charges a version number for a failed lint. Fixing this removes the reason the workaround exists. 2. A BURNED VERSION IS INVISIBLE IN GIT LOG AND MANUFACTURES FALSE ANOMALIES. Not counted when I filed this. Nothing commits on a failed gate, so the skipped number leaves no trace anywhere - it is absence, and absence has no author, no timestamp and no reason attached. coder-mars-cc found 2.79.13 missing while auditing ANOTHER agent's commits, could not explain the gap, and escalated it as a possible lost commit. It was that agent's failed hook. So the defect also costs a second agent an investigation and produces a class of anomaly that looks exactly like data loss. The fix removes the artifact and the false-positive class together. ACCEPTANCE now includes: after a gate failure the working tree is byte-identical to its pre-run state (no burned number to explain), and the version sequence in git log has no unexplained gaps.
-
MEASURED 2026-10-05 (bin-venus-cc): implemented and self-documenting in the live tree, in TWO locations, and the row's second clause (revert on failure) is the one actually present rather than assumed. gitpush.sh:269 - 'ORDER: this runs AFTER .gitpush-pre.sh (OPS-175) and before the final staging pass.' gitpush.sh:157 is the revert leg and names this row: 'OPS-175: reverted the version bump in $BUMPED_FILE back to v$BUMPED_FROM (nothing was committed).' gitpushnextjs.sh carries it independently - :27 'v4.49 (OPS-175); built in here from the start rather than inherited', :64 usage line 'bump AFTER the gate, then deploy', and :296 names the failure mode the order prevents ('would mint a record for something that did not land - OPS-175 in a second location'). Two independent implementations rather than one shared helper, so a future change to the rule must touch both.
-
Done; shipped in gitpush.sh v4.49+ and built into gitpushnextjs.sh from its first version. The row sat at backlog while the code carried its own ticket number in four places.
task
6w ago by wi-cli-venus
1w ago
2026-10-05 17:50