gitpush.sh auto-bumps package.json: any version an agent states pre-push is not the version that ships
Found by coder-terra-cc, routed by pmmaster-evolutiva-cc 2026-09-12. FINDING, read-only, no edit made under the STOP. (1) The auto-bump is INTENDED and DOCUMENTED, not accreted: gitpush.sh --infoforllms line 913 already says 'Do NOT edit version numbers in index.html or package.json manually', and the bump is load-bearing - Elazar checks the live version to confirm a deploy went through, and v4.10's own comment records that a frozen version does not FAIL a live-version check, it makes that check PASS against a frozen deploy. So the fix is not the script; it is every convention that has an agent state a version pre-push. (2) coder-terra-cc's 'silent no-op' is one step off, and the correction matters: bump_package_json_version READS the current version and increments it, so a hand-bump is not discarded, it is ABSORBED AS THE BASE. Hand-bump 1.2.3 to 1.2.4, then --patch ships 1.2.5. The agent's stated version never exists, and the number that does ship is one ahead of the one it is hunting. (3) The one-line notice pmmaster asked for ALREADY EXISTS: bump_package_json_version prints 'package.json: vOLD to vNEW' in green on every run, after reading the value back rather than trusting the write. So the surface is not missing - agents are stating a version BEFORE the run and never reconciling it against that line. That makes this a convention defect, not a script defect, which is the same conclusion as (1) from the other direction. (4) ENDORSED: a version claim should only ever be read back FROM the deployed artifact, never asserted from the repo. Same family as OPS-239 and OPS-245 - the check passes without having checked. OPEN QUESTION for pmmaster: whether to add a notice when a hand-bump is detected in the working tree (the script can see package.json is dirty before it bumps) - that is a real script change and is NOT made under the STOP.
Activity
-
SHIPPED, two commits. Elazar GO relayed verbatim by pmmaster-evolutiva-cc ('go on gitpush'); the earlier warn-only ruling was WITHDRAWN by pmmaster before implementation and no warning was built. Elazar, verbatim: 'that version mismatch is a bug that has ben called fixed 100 times or more. gitpush.sh bumps the version, deploy or not, and agents bump version manually then gitpush.sh bumps it too and there is a huge confusion.' ROOT CAUSE, and it is not the one in the description: two writers to one field and no way to have one. There is no --no-bump and no opt-out anywhere in the script; with no flag it prints a red banner and defaults to patch anyway, so a bump ALWAYS happened. Every earlier fix moved WHEN the single writer runs (:394 carries three, OPS-175 moved it relative to the hook) without ever removing the SECOND writer, which is why this has been called fixed 100 times. The (4) endorsement in the description stands but was not sufficient: a convention loses to the primitive every time, so the cure had to be in the script. FIX, 8b591e7, gitpush.sh v4.58, inside bump_package_json_version so both call sites share it: the working tree is compared to HEAD. disk == HEAD bumps exactly as before, normal path untouched. disk > HEAD means an agent hand-set it, so the auto-bump is SKIPPED and that exact version ships, with the run naming it. disk < HEAD aborts as a reused or rolled-back version. An unreadable or non-semver version in HEAD also aborts, because without a readable committed value there is nothing to compare against and guessing is how this bug got here. The compare is NUMERIC per component, not lexical: a string compare ranks 1.10.0 below 1.9.0 and would turn a legitimate hand-bump into the rollback abort, a wrong answer wearing the right shape. FOLLOW-UP, 7036b9d, v4.59, on pmmaster's ruling on the one case v4.58 left open: a package.json ABSENT from HEAD now ships its DISK value unbumped and says there was no committed version to compare against. v4.58 had taken the normal auto-bump there, which reproduces the exact defect on a file's very first push, where a deliberate 0.1.0 shipped as 0.1.1 and the stated number is most likely to be believed. --infoforllms was rewritten in 8b591e7 because its old text told agents never to hand-set package.json and that instruction is now wrong; it also carries the read-back rule, which is the description's (4) made operational: a version claim comes from the deployed artifact where an endpoint exists (pluto /api/health, chat-duo-web /api/version) and otherwise from gitpush's own green read-back line, never from a number asserted before the run. VERIFIED by gitpush-bumporder.test.sh against both versions each time, local bare-repo origin, hub env unset, no real remote touched by the tests. v4.57: 4 passed 3 failed for the three right reasons. v4.58: 7/7. v4.59 arm [8]: red on v4.58 (author wrote 0.1.0, run shipped 0.1.1), green on v4.59, 8/8. Arm [2] is the anti-over-correction control and stayed green throughout, so the fix did not degenerate into never bumping. Arms [5] and [6] push their intermediate commit to the fixture origin first; without that the ahead-of-origin guard aborted the run and [6] passed for a reason unrelated to the version compare - a control that passes for a reason other than the one it tests is not a control. COVERAGE, pmmaster's own sentence verbatim: 'this exercises the strict+website+Next.js call site; the second call site shares the same function so the decision is common to both, but the non-strict path is not separately exercised by this suite.'
-
Closed on pmmaster-evolutiva-cc ruling 2026-09-12 04:34 ART. Shipped: gitpush.sh v4.59 + gitpush-bumporder.test.sh v1.3 at 7036b9d, 8/8 green on v4.59, arm [8] red on v4.58 (author wrote 0.1.0, v4.58 shipped 0.1.1). The not-in-HEAD branch now returns before the bump, in green, naming the value it ships and stating there was no committed version to compare against. COVERAGE, pmmaster's sentence verbatim and the reason the row closes rather than staying open: 'a shared function is an argument, not a measurement, and an argument is what has already failed on this bug repeatedly' - the non-strict call site at gitpush.sh:2424 is NOT exercised by this suite and is now OPS-250, p3, mine.