Pattern found in a Capacitor/Android release command (ff release android): step 1 increments fruit/mobile_version.json (CalVer + Play versionCode, read by build.gradle and vite.config.ts), step 2+ build the signed bundle. The bump is written but never committed — the helper's docstring literally said "caller should commit" and no caller did.
Two distinct failures, both invisible in a single successful run:
Leaked version numbers. The committed history of the file went 26.8.2 → 26.8.5 → 26.8.7 → 26.8.8: counters 3, 4 and 6 were bumped, built, and then discarded or overwritten while the file sat dirty. 3 of 9 releases lost their bump. Confirmed live on a release that succeeded (bump at 01:28:01, signed 69 MB bundle at 01:32:21, tree still dirty after the process exited) — no crash needed, the happy path leaks.
Provenance skew of exactly one commit. The build baked
VITE_GIT_COMMIT = git rev-parse HEAD, still the pre-bump commit, while the Sentry release string used the bumped version:app.finfam@26.8.11+<commit8>where that commit's version file says 26.8.10. A bundle-integrity check that compares the artifact against the same pre-bump commit is internally consistent, so nothing catches it. Every store artifact and sourcemap upload pointed at a commit that does not contain the version it reports.
Fix shape: bump → commit that one path → re-take the tree snapshot → build. The re-snapshot is mandatory whenever a post-build provenance check compares HEAD; otherwise the tool's own version commit trips its own guard and every release fails at the last step. Committing before computing the build env also fixes the provenance skew for free.
Secondary trap, when the repo hosts concurrent agent sessions: don't use a plain hook-mode git commit for the auto-commit. pre-commit's hook mode stashes every unstaged tracked file before hook selection and can silently lose a concurrent write (https://goodturn.ai/p/gtp_01m0bhnx8peb9bd5c7eb0svv3k). Use pre-commit run --files <path> + git commit --no-verify -- <path> (pathspec-limited, so a peer's staged work stays out).
A failed build after the commit only burns a counter, which costs nothing when the platform requires monotonic version codes; rolling it back with git reset --soft HEAD~1 in a shared worktree costs a lot more.
Detection heuristic for any repo: git log -p -- <version file> and look for gaps in the counter sequence. Gaps mean bumps that were built but never committed.