Commits are authored from a GitHub-matchable email, and the push refuses to run when they are not
Decided
every commit that reaches origin/main is authored by an address GitHub can resolve to the account that owns the repository — in practice khan.ahmadz6370@gmail.com, the value git config user.email already carries, or that account's users.noreply.github.com form. push.command runs check:commit-identity against HEAD before it pushes anything, and aborts without touching either remote if the check fails.
Affects: push.command, scripts/check-commit-identity.mjs, and every future commit on main.
What went wrong. Commit f7b3efe — the LinkedIn company page — was authored as Novel Systems <engineering@novelsystems.ca>. That address is real: it is a Workspace mailbox on our own domain and it receives mail. It is not a GitHub identity, and it was never registered as one. Every layer accepted it. git commit accepted it. git push returned zero and .push-log.txt recorded origin exit status: 0. GitHub stored the commit and moved the branch tip. The failure appeared only in one place, as a status word in the Vercel dashboard:
Deployment Blocked — The deployment was blocked because the commit email engineering@novelsystems.ca could not be matched to a GitHub account.
No build ran. No build log exists to read. The site kept serving 71e5c7b and looked entirely healthy doing it, because it *was* healthy — it was just eight minutes, and then twenty, behind the branch. The published commit hash on /engineering is what eventually gave it away, which is the second time that field has earned its place on the page.
Why the guard sits in `push.command` and not in `verify` or `prebuild`. verify runs before the commit exists; HEAD is still the previous commit and the check would pass while inspecting the wrong object. prebuild runs inside Vercel, which never starts a build for a blocked deployment — the check would be locked behind the door it exists to open. The pre-push hook is the only point where the offending commit is already formed and the consequence has not yet been paid.
What was not done: `f7b3efe` was not rewritten. git commit --amend --reset-author would have produced a correctly-authored commit, but the original was already on origin, so landing it would have meant a force-push over a shared branch to fix a cosmetic field on one commit. The deployable state is a property of the branch tip, not of every commit in history, so the repair is the ordinary one: land the next commit correctly and let Vercel build that. f7b3efe stays in the log with an email that resolves to nothing, which is a fair record of what happened.
Wrong if: a second person starts committing, or commits begin arriving from CI or a bot. The allowlist is two entries wide because the repository has one author. Adding a contributor means adding their address, and the failure message is written to make that the obvious next step rather than a puzzle. The check also cannot see whether an address is *verified* on the account — only GitHub knows that — so the list records addresses observed to produce a deployment that reached "Ready", not addresses derived from first principles.