gitpush.sh gated version-target resolution on BUMP_LEVEL, so a no-bump push was silent about the version it did not move - and the push-to-deploy floor was reading that version as proof
DEFECT, measured by coder-venus-cc on venus 2026-10-06 and confirmed here by reading the code: gitpush.sh wrapped the ENTIRE bump block in 'if [[ -n $BUMP_LEVEL ]]', including the resolution of which file holds the version. So a push with no --patch/--minor/--major did not merely skip the bump - it could not SAY it had skipped one, because nothing had worked out whether the repo has a version file at all. No level meant no target, no bump, no output, exit 0. EVIDENCE: package.json byte-identical at 1.17.38 across SIX pushes (7a09179, adff953, b4d03db, 0bf0e98, 11778c9, 6964dbe), last actually touched at 7a09179 (1.17.37->.38); before that, one bump per push. Nothing in those six runs' output said so. Meanwhile the push-to-deploy floor was reading the live version as evidence of a deploy. A MANDATORY FLOOR CANNOT READ AN OPTIONAL, SILENT FIELD - and coder-mars-cc is amending the commons in parallel so the PTD floor binds on deploymentId with version demoted to corroboration, which is the right half of the fix on their side. CLOSED HALF, SHIPPED AS v5.7: target resolution moved OUT of the level check, so the no-level path names the version file it did not touch, says the floor binds on deploymentId, and says the live version will not move for this push. WARNS ONLY. Fires only where a version file exists - sh.git itself has no .bump, package.json or index.html, so it stays quiet here, which is also what makes the control real. A broken .bump is still fatal ONLY when a level was given: promoting it to fatal on every push would abort lanes that never asked to bump. FORCED RED BEFORE ACCEPTANCE: gitpush-nobump-notice.test.sh v1.0, 7 assertions, scored 5 passed / 2 FAILED against the deployed v5.6 (no notice, no deploymentId orientation) and 7/0 against v5.7. Case [2] keeps case [1] honest by asserting SILENCE in a repo with no version file - an unconditional notice would print on every sh.git push and be trained away within a day. Case [4] covers both halves of the .bump fatality. Siblings re-run green against the candidate: gitpush-hookscope 6/0, gitpush-prestage-abort 17/0. OPEN HALF, RESERVED TO ELAZAR, which is why this row is not closed: coder-venus-cc offered three remedies - refusal, default, or a warning. I took the warning because it breaks nobody. The other two are fleet-wide behaviour changes: refusing a no-bump push breaks every docs-only and test-only push, and defaulting to --patch mints versions nobody asked for (the monolith had exactly that red 'defaulting to --patch' box and it was removed). Ask: should a no-bump push to a repo WITH a version file be refused outright, default to --patch, or stay a warning? The test file says in its header not to add cases for refusal or defaulting until he rules.
Activity
-
Closed half PUSHED as 1d64ed9 (gitpush.sh v5.7 + gitpush-nobump-notice.test.sh). Row stays OPEN on the refusal-vs-default-vs-warning question, which is Elazar's.
-
Open half only: should a no-bump push to a repo WITH a version file be refused, default to --patch, or stay the v5.7 warning? Refusal and defaulting are both fleet-wide behaviour changes, so they are Elazar's call, not mine and not a peer's. The warning is shipped and breaks nobody; nothing is waiting on this.