# Handoff — 2026-09-01 — the build checks the version it stamped

## State

Done. `scripts/check-version.sh` runs the freshly built binary and compares what it reports against what the build meant to stamp. It is called from three places:

| Caller | When | On failure |
| --- | --- | --- |
| `make build` | after linking | the build fails |
| `scripts/install.sh` | on the staged binary, before the rename | nothing is installed; the binary already there is untouched |
| `03-build-releases.sh` | on the one staged asset this machine can run | the release build stops |

Eight tests in `version_check_test.go`; three of them falsified. Suite green, quality gate PASS 0/0/0. Documented in `docs/{en,fr}/reference/versioning.md`.

## In flight

Nothing.

## Next steps

1. Nothing specific — it ships with the rest of the branch.

## Open questions / blockers

- None.

## Watch out for

- **The comparison must stay an equality.** `0.2.0` is a substring of `10.2.0` and of a commit hash that happens to contain it. The release script used `grep -qF` and would have accepted either; there is a test named for exactly that case.
- **The check goes before the install, not after.** A binary that cannot name its own version must never replace one that can, and there is a test asserting the ordering in `install.sh`.
- **The failure this catches is silent.** `-X` naming a symbol that does not exist is not a link error. If you rename anything in turbo-core's `version` package, the Makefile's `-X` paths go stale and *nothing* says so except this check.
- **An unstamped build is legitimate.** Installing from a tarball has no git checkout to describe, so the check is called with no expected version and only refuses `unknown`.