## TL;DR
The bump went to the release branch, which is the production line, instead of main where it gets full review. Retarget the PR to main (or cherry-pick the commit), review it properly, and teach the agent to verify the base branch before opening.

## Error
```text
agent opened the upgrade PR against the release branch instead of main  -  the bump shipped to production without review
```

## Steps
1. Check whether the PR merged: if it is still open, change the base to main in the PR UI; if it merged, revert or cherry-pick the commit onto main.
   Expected output: The change lives on main with a proper review, and the release branch is clean.
2. Audit what shipped: if the release branch deployed with the unreviewed bump, verify the dependency behaves in production and note the incident.
   Expected output: You know exactly what production is running.
3. Add the base-branch rule to the agent's instructions: upgrade PRs target main unless the task explicitly says hotfix.
   Expected output: The agent states its intended base branch before opening.
4. Protect the release branch so only hotfix-labeled PRs from authorized users can merge.
   Expected output: A mis-targeted upgrade PR fails the merge gate.

## When to use
- An upgrade PR targets the release or production branch by mistake
- A bump shipped to production without the usual review
- You are writing branch-targeting rules for an agent

## When not to use
- Deliberate hotfix bumps; those belong on the release branch
- PRs that were correctly retargeted after discussion
- Long-lived feature branches with their own update policy

### Variant phrasings
#### dependency PR opened against release branch instead of main
#### bump merged to production branch without review
#### change PR base branch from release to main

## Why it happens
The agent picks a base branch from recent context or defaults, and release branches look like the "important" branch. Nothing in its instructions pins main as the default target for upgrades, so the PR goes where the agent thinks it matters most.

## Edge cases
- Changing the base of an open PR can create conflicts if the branches diverged; resolve on the new base and re-run CI.
- If the release branch has its own lockfile, the same bump may be needed there too as a deliberate, reviewed hotfix.
- Some repos use main as the release line; adapt the rule to your actual branching model.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_7hcAsovvNAzi5iLl9E_H0Q