agent's upgrade schedule fired during the code freeze — 12 PRs opened against a frozen main

Not specified by the original author.

TL;DR

The bot's schedule does not know your release calendar. Close or retarget the 12 PRs, add the freeze window to the schedule configuration, and give the agent a freeze flag it must check before opening PRs.

Error

agent's upgrade schedule fired during the code freeze  -  12 PRs opened against a frozen main

Steps

1. List the PRs opened inside the freeze window and check whether any merged. Expected output: You know which PRs need closing, retargeting, or reverting.

2. Close the unmerged ones with a note that they were opened during the freeze; keep them as drafts if you want the work preserved. Expected output: The frozen branch has no pending upgrade PRs.

3. Add the freeze dates to the bot's schedule config (exclusion windows) or pause the schedule for the freeze duration. Expected output: The schedule skips the freeze window next time.

4. Add a freeze check to the agent's instructions: read a freeze flag (a repo file, a label, or a calendar) before opening any PR. Expected output: The agent refuses to open PRs while the flag is set.

5. After the freeze lifts, re-open the updates in the normal schedule. Expected output: The updates land on an unfrozen branch with proper review.

When to use

• Upgrade PRs appeared during a code freeze or release lockdown
• You are planning a freeze and want the bot quiet beforehand
• The schedule config has no concept of freeze windows

When not to use

• Emergency security hotfixes during a freeze; those are exempt by design
• PRs opened before the freeze that are still pending; let them ride or close them deliberately
• Human PRs violating the freeze; that is an access problem

Variant phrasings

renovate opened PRs during the release freeze

pause dependency updates during code freeze

upgrade schedule ignored the freeze window

Why it happens

Update bots run on cron schedules that are blind to release calendars. Unless the freeze window is encoded in the schedule config or the agent is taught to check a freeze flag, the bot keeps opening PRs against a branch nobody is allowed to merge into.

Edge cases

• A freeze that starts mid-schedule-run can still open PRs; pause the scheduler itself, not just the config.
• Security updates may need to proceed during a freeze; carve them out explicitly rather than hoping.
• If any freeze-window PR merged, treat it as a freeze violation: review and possibly revert.

Provenance

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

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

Thread query: agent's upgrade schedule fired during the code freeze - 12 PRs opened against a frozen main

TL;DR: The bot's schedule does not know your release calendar. Close or retarget the 12 PRs, add the freeze window to the schedule configuration, and give the agent a freeze flag it must check before opening PRs.

Not specified by the original author.

TL;DR: Do not close and reopen to refresh a stale PR - update the existing branch in place by rebasing or merging main and pushing. Closing discards the review thread and the approved CI run, and the new PR starts from zero trust. If the old branch is truly unrecoverable, link the closed PR prominently in the new description and carry the review conclusions over.

agent closed a stale upgrade PR and opened a fresh one, losing the review thread and the approved CI run

1. Check whether the old PR's branch still exists and whether the PR can be reopened. Expected: you know if in-place recovery is possible or the branch is gone.
2. If the branch exists, reopen the old PR (or push the refreshed branch to it) and close the duplicate. Expected: a single PR carrying the full review and CI history.
3. If the branch is gone: in the new PR description, link the closed PR and paste the key review conclusions plus the approved CI run link. Expected: reviewers see the carried-over context without digging through closed PRs.
4. Re-run CI on the surviving PR and re-request review, noting explicitly what changed versus the closed one. Expected: fresh approvals on the actual code being merged - nothing carried over silently.
5. Teach the agent: stale PRs get refreshed in place; close-and-reopen is only for a corrupt branch, and then a link-back is mandatory. Expected: future stale PRs keep their threads.

Use this when

• An agent closed an upgrade PR and opened a duplicate
• Review comments or an approved CI run were lost in the shuffle
• You need to recover continuity between the old and new PR
• A bot or agent keeps "refreshing" PRs by closing them

Not for this skill when

• The PR was closed because the upgrade itself was abandoned - that is fine
• The new PR properly supersedes the old one with a link-back already in place
• Your workflow already refreshes PRs in place with rebases

Variant phrasings

• Agent reopened upgrade PR, lost review comments
• Closed stale PR and opened new one, lost approvals
• Duplicate upgrade PR
• Refresh by close-and-reopen lost CI history

Why it happens

The agent treats "stale" as "broken" and its refresh primitive is close-plus-open, because it does not model review threads and CI approvals as state that lives on the PR object. To the agent the diff is identical, so the new PR looks equivalent - but the human trust (reviews, green runs) was attached to the old PR number, not to the diff.

Edge cases

• Some repos auto-delete branches on close - restore the branch from the reflog or a local copy first
• If main moved on, the reopened PR needs a rebase anyway - watch for the approval-invalidation trap when you do
• Bots that auto-close stale PRs need an exemption label for agent upgrade PRs under active review

Provenance

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

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

Thread query: agent closed a stale upgrade PR and opened a fresh one, losing the review thread and the approved CI run

TL;DR:

Not specified by the original author.

TL;DR: Security updates always ship in their own PR, separate from every other bump. Split the security patch out of the grouped PR, merge and release it first, then deal with the major on its own timeline. Configure the agent to treat security-flagged updates as their own group with priority handling. A CVE fix must never wait on unrelated breakage.

agent grouped a security patch with a major upgrade; the security fix couldn't ship until the major's breakage was fixed

1. Identify the security-flagged update inside the grouped PR (advisory ID, CVE number, or the scanner's severity label). Expected: one clearly-labeled security bump among the grouped changes.

2. Cherry-pick just the security bump onto a fresh branch and open it as its own PR with the advisory reference in the body. Expected: a minimal PR containing only the security fix.

3. Run CI on the security PR alone and merge it as soon as it is green, on the normal release train or hotfix path. Expected: the CVE fix ships while the major is still being fixed.

4. Leave the major upgrade in its own PR to be fixed and reviewed on its own timeline. Expected: the major's breakage no longer blocks anything security-related.

5. Change the agent's grouping config so security-flagged updates always form their own group, separated from feature and major bumps, with automerge-on-green if your policy allows it. Expected: the next advisory arrives as a standalone PR by default.

Use this when

• a CVE fix is bundled with an unrelated major upgrade
• a security patch is blocked by someone else's breakage
• the agent groups all updates into one PR regardless of severity
• auditors ask why a known CVE sat unpatched for weeks

Not for this skill when

• the security fix itself requires the major upgrade (then they are genuinely coupled; document why)
• the "security" label is a false positive from the scanner (downgrade the severity first)
• your policy forbids automerge on security PRs (keep the separate PR, just review it manually)

Variant phrasings

• "security patch stuck behind major upgrade"
• "CVE fix blocked by grouped PR"
• "renovate grouped security update with major"
• "how to separate security updates from regular bumps"
• "dependabot security PR mixed with feature upgrades"

Why it happens

Grouping rules usually key on schedule or package, not severity, so a security patch lands in whatever group was forming that day. The agent sees one fewer PR as a win. But security fixes and major upgrades have opposite risk profiles: the patch must ship fast with minimal change, the major needs slow careful review. Bundling them forces the fast item to move at the slow item's pace, which is exactly backwards.

Edge cases

• Some advisories only publish a fix on the new major line; then the security PR legitimately includes a major. Say so in the PR body so reviewers know it is not optional.
• Backport branches may need the same security patch separately; check whether the advisory affects maintained older lines.
• Automerging security PRs can still break the build; keep the CI gate, just skip the human review queue when policy allows.
• If the scanner flags a devDependency CVE as critical, weigh exploitability before hotfixing; not every critical needs the fast lane.

Provenance

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

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

Thread query: agent grouped a security patch with a major upgrade; the security fix couldn't ship until the major's breakage was fixed

TL;DR: