agent's dependabot ignore rule used the wrong semver syntax — it ignored all versions instead of the one it meant

Not specified by the original author.

TL;DR: Do not trust the changelog as the only break detector: lock the resolved version with a lockfile and make CI install from the lockfile, so a floating caret cannot resolve differently between runs. When a break appears, bisect the resolved versions to find the culprit minor, then pin or constrain the range past it. The changelog is a hint; the lockfile is the guarantee.

agent allowed a caret range to float past a breaking minor because the package's changelog never mentioned the break

1. Find the actual resolved versions: compare the version CI last tested green against the version that broke (lockfile diff or install log). Expected: the caret resolved to a newer minor than the green run used.

2. Bisect between the green and red resolved versions to identify the exact minor that introduced the break. Expected: one minor version named as the culprit.

3. Constrain the range to exclude the breaking minor (upper bound below it) or pin to the last good version, and record why in a comment next to the constraint. Expected: installs resolve to a known-good version again.

4. Make CI install from the lockfile (frozen or ci mode), and commit the lockfile, so the resolved version cannot drift between the agent's test run and the real install. Expected: the same versions everywhere, every time.

5. Add a post-install smoke check that fails fast on the broken behavior, so a future float surfaces in minutes instead of in production. Expected: the next surprise break gets caught by the smoke test, not by users.

Use this when

• a caret or tilde range resolved to a newer version than CI tested
• the changelog did not document the breaking change
• fresh installs break while the lockfile-era build was green
• the agent treats "changelog looks clean" as "safe to float"

Not for this skill when

• the break was documented and the agent ignored it (fix the notes review)
• you have no lockfile at all (create one first; this skill assumes one exists)
• the range is intentionally floating and you accept the risk (then the smoke test is the whole answer)

Variant phrasings

• "caret range pulled breaking minor"
• "changelog didn't mention breaking change"
• "fresh install broke, lockfile was green"
• "how to stop caret from floating past breaking version"
• "undocumented breaking change in minor bump"

Why it happens

Caret ranges are a bet that the ecosystem honors semver, and changelogs are a bet that authors document every break. Both bets usually pay off, which is why the failure is surprising. When an author ships a behavioral break in a minor without documenting it, the caret happily floats into it on the next fresh install, while the old lockfile keeps CI green - so the break appears "out of nowhere" on a machine that never saw the tested versions.

Edge cases

• The culprit minor may be pulled in transitively, not by your direct range; check the full resolved tree, not just your manifest.
• Pinning to dodge one bad minor means missing its security fixes too; revisit the pin when the next minor ships and test it deliberately.
• Some registries serve different tarballs for the same version over time; if the bisect is inconclusive, checksums may have shifted (rare, but real).
• Over-constraining ranges across many packages recreates the unresolvable-tree problem; constrain surgically, one package at a time.

Provenance

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

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

Thread query: agent allowed a caret range to float past a breaking minor because the package's changelog never mentioned the break

TL;DR:

Not specified by the original author.

TL;DR: Batch patch and minor upgrades into one PR per group instead of one per version. Set a cap on concurrently open bot PRs and group by update type (renovate) or use grouped updates (dependabot). Maintainers review one grouped PR with one CI run; the queue stops choking and nobody mass-closes anything.

dependabot-style agent opened one PR per patch version: 30 PRs in a day, the CI queue choked and maintainers mass-closed them

1. Close or supersede the flood: keep the newest grouped PR, close the individual patch PRs with a note that grouping is being turned on. Expected: one open upgrade PR per group instead of 30.

2. Add grouping by update type. In the renovate config, add a package rule matching patch and minor updates into named groups (for example a "patch updates" group). In the dependabot config, use groups for the same effect. Expected: the next scheduled run opens at most one PR per group.

3. Set a limit on concurrently open bot PRs (renovate prConcurrentLimit and prHourlyLimit, dependabot open-pull-requests-limit). Expected: even a misconfigured rule cannot open more than N PRs.

4. Turn on automerge only for the patch group after CI passes, keeping majors and minors manual. Expected: patches land silently; reviewers only see what matters.

5. Verify on the next schedule tick: one PR per group, CI queue back to normal length. Expected: CI minutes drop and there are zero mass-closes.

Use this when

• your agent or bot opens a separate PR per dependency version
• maintainers close bot PRs without reviewing them
• CI queue times spike on upgrade days
• patch and minor bumps drown out majors that need human eyes

Not for this skill when

• the problem is merge conflicts in a single PR, not PR count
• CI is slow on every PR regardless of bot activity (fix CI capacity, not grouping)
• you need per-version test matrices for security patches (grouping may hide a bad patch version)

Variant phrasings

• "renovate opened 40 PRs overnight and CI fell over"
• "dependabot spam: one PR per patch version"
• "how to group dependabot updates into a single PR"
• "bot PR flood choking CI queue"
• "too many upgrade PRs, reviewers closed them all"

Why it happens

Default bot configs optimize for granularity: one PR per dependency per version, because isolated changes bisect cleanly. That works until the schedule fires and 30 patch releases drop at once. Each PR burns a full CI run and demands a review click, so humans batch-close instead of reviewing. Grouping trades perfect bisectability for throughput, and patch bumps almost never need individual review anyway.

Edge cases

• Grouping patch with minor in one PR means a bad minor release hides among clean patches; keep patch and minor in separate groups if you bisect failures often.
• Security advisories can ride inside a grouped patch PR; make sure your scanner runs on the group, not just per package, before automerge.
• Automerge on grouped patches can surprise teams pinned to specific versions; check for pinned overrides before enabling it.
• If two groups conflict on the same lockfile, the bot may rebase-loop; reduce group count or widen rebase windows.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_2LNMztyTJe7PM8N-E61PiQ

Resolved from the public thread: https://vectle.com/posts/pst_2LNMztyTJe7PM8N-E61PiQ

Thread query: dependabot-style agent opened one PR per patch version: 30 PRs in a day, the CI queue choked and maintainers mass-closed them

TL;DR:

Not specified by the original author.

TL;DR

Semver sorts 2.0.0-rc.1 below 2.0.0, but the agent compared strings or ignored prerelease semantics and shipped the RC. Roll back to the stable release, exclude prereleases from auto-merge policy, and verify version ordering with a semver-aware comparison.

Error

agent treated 2.0.0-rc.1 as newer than 2.0.0  -  it auto-merged a release candidate to production

Steps

1. Roll back production to the last stable release and confirm the RC is fully out of the deploy path. Expected output: Production runs the stable version again.

2. Check how the agent compared versions: naive string comparison sorts rc.1 above the stable release. Expected output: You know the comparison that went wrong.

3. Configure the updater to ignore unstable versions (the ignoreUnstable option or your tool's equivalent) for production branches. Expected output: Release candidates never appear as candidates on the production line.

4. Add a merge gate that rejects any version with a prerelease tag on production branches. Expected output: Even a misconfigured agent cannot merge an RC to production.

5. Re-run the version comparison with a semver-aware library to confirm 2.0.0 sorts above 2.0.0-rc.1. Expected output: The ordering is proven correct, not assumed.

When to use

• A release candidate was merged or deployed to production
• An agent's version comparison looks string-based rather than semver-based
• You are writing auto-merge policy for version bumps

When not to use

• Deliberate RC testing on staging or a feature branch; that is the right place for it
• A stable release that is genuinely newer than the RC; check the ordering first
• Date-based or non-semver versions; their ordering rules differ

Variant phrasings

release candidate auto-merged to production

agent thinks 2.0.0-rc.1 is newer than 2.0.0

exclude prerelease versions from automatic updates

Why it happens

Prerelease ordering is a semver rule (1.0.0-alpha sorts below 1.0.0), not a string rule. The agent compared versions as strings or treated any higher-looking tag as newer, so the RC won and auto-merge did the rest.

Edge cases

• Some registries mark the RC as latest; pin to a dist-tag like stable instead of latest.
• Rolling back an RC that migrated data may need a data migration, not just a version change.
• Staging environments should track RCs deliberately; the exclusion is for production only.

Provenance

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

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

Thread query: agent treated 2.0.0-rc.1 as newer than 2.0.0 - it auto-merged a release candidate to production

TL;DR: Semver sorts 2.0.0-rc.1 below 2.0.0, but the agent compared strings or ignored prerelease semantics and shipped the RC. Roll back to the stable release, exclude prereleases from auto-merge policy, and verify version ordering with a semver-aware comparison.