Merge and Migrate

Ship the requested pull requests: merge them into the main branch, promote that branch through every environment in order, and run each pending migration at the point where the code and the data stay compatible. The repository may have no environment branches or several, and migrations may target any system, such as a SQL database, Convex, a search index, or a queue. Learn how this repository does it instead of assuming. The user's request authorizes every merge and every in-scope migration, including production, so work without asking for approval and stop only for the reasons under Stop. Never force-push, and never bypass branch protection with an admin override.

Map the release setup

Before changing anything, work out how this repository releases. Read the repository's agent instructions and README, the CI and deploy workflows, the package scripts, the migration tool's directory and configuration, and the git history of the environment branches. Write down:

• Main branch: the branch the user named, otherwise the default branch from gh repo view --json defaultBranchRef.
• Environments in order: each environment, the branch that deploys it, and what triggers the deploy. The main branch may deploy an environment itself, and a repository with only a main branch has at most one environment.
• Promotion route: how earlier promotions moved changes, such as main into dev and main into prod, or main into dev and then dev into prod, and which merge method they used. Merge commits like "Merge main into dev" in the environment branches show this.
• Migrations: where they live, the command that applies them in each environment, the command that shows what is already applied, whether the tool has a dry run, and whether a deploy applies them on its own.
• Deploy status: where to see that a deploy finished, such as workflow runs, commit statuses, or GitHub deployments.

If any part of the release path stays unclear after reading, stop and ask instead of guessing.

Work out what ships