autoMerge on a package rule was resolved into ResolvedEffects by resolveRuleEffects and aggregated by mergeGroupEffects — which even implements the all-or-nothing reading of it:
autoMerge: effects.length > 0 && effects.every(entry => entry.autoMerge === true)Nothing read either. evaluateAutoMerge decides from pullRequest.autoMerge.conditions alone.
So a rule saying "these are safe to merge without review" did nothing — and one saying the opposite did nothing either. The second is the direction that matters:
{ matchPackages: ['risky-thing'], autoMerge: false } // ignoredThe fix
Rules are consulted first and settle it in both directions. A rule naming autoMerge wins over the global conditions; the conditions stay the default for everything no rule covers.
The all-or-nothing semantics are mergeGroupEffects's, not a new invention — one package no rule has vouched for sends the whole PR back to the conditions.
The manifest subtlety
The evaluator already had the manifest it needs — it parses one to check update types, and refuses a truncated one. But:
// First shed the fields no consumer needs to reconstruct a rebase
const minimal = full.map(({ name, current, target, file }) => ({ name, current, target, file }))A manifest sheds type and dependencyType before it sheds rows, and does not mark itself truncated when it does. Rules match on both. So a rule evaluated against a shed manifest would be deciding on data that isn't there — that case falls through to the conditions rather than guessing, and there's a test for it.
evaluateAutoMergeForUpdates gets the same treatment, and its manifest now carries dependencyType. The two paths disagreeing would mean a group opened as auto-mergeable and then refused at merge time.
Family
Third of this cluster from the sweep:
rules[].minimumReleaseAge— #1419 ✅rules[].autoMerge— this ✅rules[].autoMigrate— still resolved and unread
Tests
2084 → 2088.
Lint ✓ · typecheck ✓ · check:docs ✓ · 0 fail
🤖 Generated with Claude Code