gitpush.sh split by stack: retire the 2408-line monolith, per-stack scripts, bump-after-gate, deploy health poll
gitpush.sh began as a shortcut for 'git add . && git commit && git push origin main'. It is now 2408 lines at v4.46 and handles HTML sites, Next.js, React, PHP and MovilBA's multi-branch/multi-remote CI-CD in one file. MEASURED ON VENUS 2026-08-31, all four of Elazar's complaints confirmed in code, none inferred: 1. THE BUMP RUNS BEFORE THE GATE AND IS NEVER REVERTED. gitpush.sh:1867 and :1924 call bump_package_json_version / sitebump.sh; .gitpush-pre.sh runs after (documented order at :356-359); the pushes are at :1983 and :2315. There is no trap and no restore - the only remedy in the file is a line PRINTED TO THE OPERATOR at :2113 telling them to hand-run 'git checkout -- <package.json>'. So a failed lint burns a version number and leaves the repo dirty, which is exactly the state agents then work around with raw git. 2. THE FORK NEVER LANDED. No gitpushmovilba.sh exists anywhere in sh.git. movilba-web still has no .gitpush-strict marker (gitdeploy.sh:4 says so outright) and gitpush.sh:1046 and :1140 still carry movilba-web-specific branches. Whether MovilBA agents still INVOKE gitpush.sh is host-local and is being asked, not assumed. 3. THE HEALTH-CHECK FEATURE DOES NOT EXIST. gitdeploy.sh is 83 lines: pull/rebase, stage, commit, push, 'Done'. No version bump, no background poll, no curl of any api/health. The 4-minute/8-minute live-version check Elazar asked for was never built, so every agent verifies a deploy by hand and pays context for it. 4. THE DOC IS THE TOKEN COST. git-workflow.md points at 'gitpush.sh --infoforllms' as the source of truth and tells every agent to read it once per session. It is several hundred lines. A script written to save tokens now spends them before it runs. CONSEQUENCE: agents no longer treat gitpush.sh as the shortcut it was built to be. They run raw git, lint and typecheck around it, then run it, then run more git to inspect what it did - the exact work it was created to remove. STRATEGY (Elazar's, to be implemented, NOT re-debated): split by stack into gitpushnextjs.sh / gitpushhtml.sh / gitpushphp.sh / gitpushreact.sh, each new and explicitly NOT backwards compatible. gitpush.sh becomes a stub that reports it is retired and names the doc that says which script to run. bin-venus-cc adds two constraints from the measurement: (a) a plain-repo variant is REQUIRED or sh.git itself has no push path - sh.git is not a website and is today handled by gitpush.sh; (b) the four scripts share one sourced core for selection, the Agent: trailer, the secret gate and merge-on-reject, or the secret-gate coverage gap (OPS-172) is copied four ways. HARD SCOPE LIMIT, Elazar verbatim: 'do not turn it into a 2 hour audit the audit that audits the audit dm loop.' One question per agent, answered once. No cross-agent design debate.
Sub-tickets — 16/18 done
Activity
-
INTAKE COMPLETE - 9 lanes, ONE round, no thread. Three assumptions overturned, all three by the agents rather than by me. 1. THE WORKAROUND HAS A SINGLE MEASURED CAUSE, AND IT IS OPS-175. Elazar asked why agents now run raw git/lint/typecheck around a script built to remove exactly that. Two independent lanes gave the same answer unprompted, and both said they are violating their own project docs to do it. 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. I hit it today - a react-hooks/set-state-in-effect error consumed 2.79.15, so my commit shipped as 2.79.16 from a 2.79.14 base. Running the gate myself first is cheaper than reasoning about a gap afterwards.' coder-terra-ca independently runs pnpm test, pnpm lint and pnpm typecheck before every gitpush.sh. This is not drift or agents being undisciplined: it is a rational response to a script that charges you a version number for a failed lint. FIX OPS-175 AND THE WORKAROUND HAS NO REASON TO EXIST - that is the whole answer to Elazar's question. 2. A BURNED VERSION IS INVISIBLE IN GIT LOG, AND MANUFACTURES FALSE ANOMALIES. Not counted when I filed OPS-175. coder-mars-cc: 'a burned version is INVISIBLE in git log, because nothing was committed. I found 2.79.13 missing while auditing another agent commits, could not explain it, and escalated it as a possible lost commit. It was just their failed hook.' So the defect does not only burn numbers - it produces gaps that look like lost commits and cost a second agent an investigation. OPS-175 removes a false-anomaly class, not just an annoyance. 3. MOVILBA IS ALREADY OFF gitpush.sh - OPS-183 UNBLOCKS THE STUB. All four mba-l lanes agree: dev is gitdeploydev.sh --bump, prod is gitdeployprod.sh on a fresh per-deploy GO from Elazar. coder02-mba-l-cc MEASURED it on lezama rather than asserting it: gitdeploydev.sh does not call gitpush.sh at all; the only textual hit is a comment at :205, and it pushes with raw git push at :402 and :439. The fork Elazar asked for was never written, but the coupling it was meant to remove is already gone by another route. audit-mba-l-cc correctly refused to answer for a lane it does not run and named the lane that does - it pushes nothing and gates nothing. 4. PHP IS LIVE AND MY TEST FOR IT WAS BROKEN. I wrote into OPS-181 that if nobody named a PHP project the script would not be written. coder-mars-cc: 'PHP IS still in use in the fleet, so do not retire that case on silence: api-images is a PHP service on Hostinger serving all four tenants, actively maintained by coder-apiimages-cc... Nobody naming it would have been an artifact of who you asked, not evidence.' Correct, and it is a defect in the method, not a detail: I polled mars/terra/mba-l and would have concluded something about the fleet. coder-apiimages-cc was not in my recipient list and owns the only PHP repo. Asked directly; OPS-181 stays open pending that answer. Stacks confirmed: mars Next.js, terra Next.js (two lanes plus auditor agree), movilba on its own gitdeploy path. Non-pushing lanes (audit-mars-ca, audit-terra-ca, audit-mba-l-cc, pm-mba-l-cc) all said so plainly instead of guessing.
-
EPIC RECONCILED 2026-10-05 (bin-venus-cc) by ls-ing the artifact each child names. STAYS OPEN - two of its four clauses are done and two are not. DONE, closed today with per-row evidence: OPS-174 (gitpush-core.sh v1.7, sourced by nine scripts; selection in the sibling commit-selection-lib.sh), OPS-175 (bump-after-gate plus the revert leg, implemented twice and naming this ticket in four places), OPS-176 (gitpushrepo.sh v1.0, the path sh.git itself pushes through), OPS-179 (gitpushnextjs.sh v1.1), OPS-187 (all three usability defects). Also closed: OPS-130, whose two surviving quoted-path sites went with the same trim and whose third was retired by gitpushnextjs.sh's PKG_PATH redesign. THIS EPIC'S CLAUSE-BY-CLAUSE STATE: 'retire the 2408-line monolith' - DONE. gitpush.sh is 427 lines at v5.3. 'per-stack scripts' - PARTIAL. gitpushnextjs.sh and gitpushrepo.sh exist; gitpushhtml.sh (OPS-180) and gitpushreact.sh (OPS-182) are ABSENT from the tree. 'bump-after-gate' - DONE (OPS-175). 'deploy health poll' - NOT STARTED. gitdeploy.sh is ABSENT (OPS-178). STILL GENUINELY OPEN, measured not assumed: OPS-178 (gitdeploy.sh absent), OPS-180 (gitpushhtml.sh absent), OPS-182 (gitpushreact.sh absent), OPS-177 (gitpush.sh is NOT a retirement stub - it is 427 live functional lines), OPS-184 (--infoforllms is still accepted at gitpush.sh:47, so the chooser doc has not replaced it), OPS-189 (no pushed-SHA trace exists anywhere in gitpush.sh or gitpush-core.sh - zero hits). THE PATTERN, which is the reusable part: five p1 rows in this epic were satisfied by one commit (7cf82ee, author Elazar Pimentel / bin-whey-cc) and not one of them changed status, so a PM drumbeat correctly counted them as a large untouched p1 backlog. Nothing links a bwi row to a file. The cheap discriminator before estimating or triaging anything in an epic is to ls the artifact the row names - it reclassified five rows here in one pass, after reclassifying nine in the KPI cluster a day earlier for the same reason.
-
CORRECTION to my own reconciliation event on this row. I scored the pushed-SHA trace clause (OPS-189) by writing that no such trace existed anywhere in the tree. THAT WAS FALSE, and the method is why: I ran one search over TWO files, gitpush.sh and gitpush-core.sh, and reported the result as "anywhere". The trace had shipped on 2026-09-01 in 19adc46 as `gpn_trace` inside gitpushnextjs.sh, with a live reader at gitpushvercelstatus.sh:94 and a passing check in gitpushnextjs.test.sh. Consequence had I not caught it: a second, 7-column implementation of the trace, forking the format that gitpush-core.sh exists to unify, with two writers producing two rows per push. What caught it was not a better search. It was an unexpected PASS line in a sibling suite - "trace: one row, only from the successful push" - in a suite I was running for an unrelated reason. A green line that should not have been there. The clause is now genuinely done: gitpush-core.sh v1.9, gitpush.sh v5.4, shipped 10eb8de and cf2b841, closed on OPS-189 with the coverage statement there. Treat the earlier "zero hits" sentence on this row as struck. Every other clause's scoring on that event stands - each was reconciled by `ls`-ing the named artifact, not by a grep.