What happens after a PR is opened and after it merges — Vercel previews, the trunk environment, and the manual path to production.
docs/DEPLOY-VERCEL.md and docs/DEPLOY-VERCEL-RUNBOOK.md. Run pnpm mf:apps for the current list of deployables.
A change reaches users through three surfaces: a PR preview, the trunk environment, and production. The runbook's environments table says when each updates, and the domain patterns for shells and remotes are in docs/DEPLOY-VERCEL.md. The shell resolves remote hostnames in the browser on every load, so any shell or remote can be promoted independently, in any order, as long as each stays compatible with the other's previous version. The deploy order section says when order matters.
pr-preview.yml ("Preview deployments") runs on pull_request_target. A trusted planning job decides which projects the PR affects, a deploy job creates Vercel preview deployments through the Vercel API, and a status job posts one comment per PR and a Preview deployments check. In a stack of PRs only the top builds a preview, unless a lower PR carries the Preview label (see Stacks: only the top builds). Previews get stable PR branch domains, and the domains are removed when the PR closes. The trust boundary, recovery steps and project provisioning are documented in .github/scripts/preview/README.md. The Preview deployments check is not required to merge. The queue's gtmq_* draft PRs skip planning and deployment unless they carry the Preview label, because each of those commits is what trunk builds after the merge.
Merging goes through the Graphite merge queue (see PR Checks and the merge-queue skill). Normal trunk builds come from Vercel's Git integration. Every trunk push also runs the preview workflow's reconciliation, which provisions a new project or completes its handoff from PR-only previews to Git deployments. The Vercel Production Branch is manual-production, so a merge deploys only to the custom trunk environment, and automatic custom-domain assignment stays off. Trunk is where to validate a change against the trunk remotes before production.
Workflows that report after a merge (metrics, baselines, deploys) trigger on push to trunk. Graphite fast-forwards trunk, so GitHub sees a push and never a merge_group event.
Production traffic moves only when someone promotes a trunk deployment, by dashboard or CLI. The runbook covers:
trunk automatically. Reaching production domains is a separate, deliberate step, so each shell and remote can ship on its own schedule.
@prepared911/ui, @prepared911/core and the rest of the Changesets allowlist): package-release-pr.yaml opens the Version Packages PR from trunk, and package-publish-changesets.yaml publishes. See docs/package-publishing.md.desktop-release.yml. Standalone apps such as auth and storybook follow their own project settings.