Findings No. 37
Vercel assigns a deployment's environment at push time, and never rebuilds a commit it has built
Redeploying keeps a deployment's original environment, pointing a branch at an already-built commit creates nothing, and git builds never read the Development target.
On Vercel, which environment a deployment belongs to is decided when the commit is pushed. Later changes to your environment setup do not reach deployments that already exist.
We learned this setting up separate dev, stage and production environments for Replicator, and three behaviours surprised us. First, Redeploy inherits the original assignment, so redeploying something created before a branch-tracking change reproduces the old, wrong environment. Second, pointing a branch at a commit Vercel has already built produces no deployment at all; a build needs a genuinely new commit. Third, a custom environment needs branch tracking (branchMatcher). Without it, pushes land as ordinary previews, miss the environment's variables and fail.
There was a related trap. Vercel's Development target is only read by vercel dev and vercel env pull. Variables set there never reach a git-push build, however reasonable the name makes that sound.
The fix in each case was procedural: after changing branch tracking, push a new commit rather than redeploying, and keep build-time variables on the Preview, Production or custom targets.
The general rule: treat a Vercel deployment as an immutable record of what was true at push time. To change its environment, make a new commit.
Receipt: Replicator environment separation (docs/environments.md; FINDINGS.md, "Vercel").