Take main off Vercel's git trigger

[7174Andy]

The follow-up promised in #9. Refs #6.

Why this was held back

#9 moved migrations into release.yml, which applies them and only then deploys. But Vercel was still deploying main off the same push, with nothing ordering the two. The first release made that concrete rather than theoretical — three GitHub deployment records for b195da1:

Time	Creator	Source
04:28:18	vercel[bot]	Vercel's git trigger
04:28:36	7174Andy	the release workflow's CLI deploy
04:30:32	7174Andy	the drift check (declares environment: production)

Two production deployments of the same commit, eighteen seconds apart. Harmless there because that release had nothing pending — but for any release carrying a migration it is a race, which is issue #6 made intermittent rather than fixed.

vercel.json closes it by disabling Vercel's git trigger for main, leaving release.yml as the only path git can trigger.

Why it was not in #9

Whether npx vercel deploy --prod still works once git.deploymentEnabled is false takes a real production deploy to find out. Landing it with #9 meant that if the answer were no, migrations would already be applied, the deploy step would fail, and there would be no remaining way to ship anything — including an unrelated hotfix.

#9's release has since deployed successfully to https://gitcron.vercel.app, so the CLI path itself is proven. The narrow remaining unknown is whether it still works with the git trigger off, and this PR is deliberately the safest possible way to test that: it carries no migration, so a failing deploy step leaves nothing half-applied, and reverting this one file restores the git trigger immediately.

What else changed

Landing vercel.json makes the interim wording false, so it goes in the same commit — three passages in README.md and two comments in release.yml that described a state which no longer exists. Stale documentation has been the recurring defect in this work: two separate reviews caught README passages contradicting the code, so leaving these for later was not an option.

The replacement text says what the file now does, that deleting it silently reopens the race with no check to catch it, and names the cost honestly — with no git-triggered fallback, a broken deploy step means no way to ship until it is fixed or this file is reverted.

⚠️ What to watch after merging

The release will run as usual: CI on main, then Migrate then deploy. Expect No pending migrations to apply. again, then the deploy.

The thing to check is the deploy step, and the deployment count. Vercel should now produce exactly one production deployment for the merge commit, created by the workflow rather than vercel[bot]:

gh api "repos/{owner}/{repo}/deployments?sha=$(git rev-parse main)" \
  --jq '[.[] | {env: .environment, creator: .creator.login}]'

Two entries with a vercel[bot] among them would mean vercel.json did not take effect on this push and the race is still open.

If the deploy step fails, the diagnosis is almost certainly that the CLI cannot deploy with the git trigger disabled. Revert this PR to restore the git trigger, then switch the deploy step to a Deploy Hook — release.yml documents that fallback, with the tradeoff that a hook only starts a build, so the step passes as soon as the request is accepted and a failed build no longer fails the release.

Nothing is at risk in the database either way: this PR touches no schema, and migrate deploy is a no-op for it.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
gitcron	Ready	Preview	Aug 1, 2026 4:35am