`buildVersion` is the piece's count of committed revisions to itself, the release gate compares it against `git rev-list --count`, and nothing moved it. It drifted every time anybody committed to oskiewar.js without remembering, and the deploy refused — twice in one afternoon, at v104 against a real count of 109 and again at v110 against 111. The refusal was doing its job. The part that was wrong is that both times the piece had been telling players an old version in the corner of the title screen while running new code, for however long the drift had been there. The number is on screen. A stale one makes every bug report cite a build that is not the build. The gate already knew both numbers at the moment it refused, so now it stamps: write, reburn the hash-bound social preview, commit, push, and restate the source against the same baseline to check the stamp actually landed. Three decisions worth keeping: A new commit, not an amend. The count is a count of commits, so an amend has to reason about whether HEAD already touched this file — and HEAD here is usually already pushed, into a checkout another session is committing to. Rewriting that history is a way to lose somebody's work. It pushes, and it has to. `lith/deploy.fish` deploys from pushed state only: it resets the box to `origin/main`. A stamp that stayed local would ship the old bytes and then fail its own hash verification, which is a worse failure than the one being fixed. It never moves a version backwards. A `buildVersion` AHEAD of the count is not drift, and it wants a person. `--no-bump` keeps the old refusal, and a dry run writes nothing. Eleven tests cover the arithmetic and the ordering, which is where an off-by-one would publish a version that disagrees with the code behind it. Also: MARKETING.md had the trim line at 500 views; the policy has been 1,000 since the underperformer line moved, and the report now prints permalinks. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>