agent's cargo update --aggressive broke a build that a conservative cargo update would have kept green

TL;DR: Default to a plain conservative cargo update (semver-compatible bumps only); reserve aggressive modes for deliberate, verified runs. The aggressive mode let the resolver ignore semver upper bounds and pull breaking versions the manifest never permitted. Restore the last green lockfile, re-run the conservative update, and verify green.

agent's cargo update --aggressive broke a build that a conservative cargo update would have kept green

1. Confirm the cause: diff Cargo.lock before and after the aggressive run, and compare against the version requirements in Cargo.toml. Expected: the lockfile contains versions beyond the manifest's declared upper bounds.
2. Restore the last green lockfile (git checkout [SHA] -- Cargo.lock). Expected: the build is green again on the conservative module set.
3. Re-run the conservative update: plain cargo update with no aggressive flag. Expected: only semver-compatible bumps; the build stays green.
4. If you genuinely need the aggressive bump (for example a security fix), do it deliberately: widen the manifest bounds first, then update, then run full verification. Expected: the breaking bump is explicit and tested, not a side effect of a flag.
5. Teach the agent: the aggressive mode is never the default update command. Expected: runbooks list the conservative update first, with the aggressive mode gated behind explicit approval.

Use this when

• An aggressive update mode broke a previously green build
• Cargo.lock contains versions beyond the manifest bounds
• You need conservative-vs-aggressive update policy for an agent
• A "routine" update pulled breaking changes

Not for this skill when

• A plain conservative update broke the build - that is a bad upstream release, different issue
• You are intentionally widening version bounds
• The failure is a registry or download error, not a version selection problem

Variant phrasings

• cargo update aggressive broke build
• Aggressive update pulled breaking versions
• Conservative cargo update would have stayed green
• Update ignored semver bounds

Why it happens

The conservative resolver only selects versions compatible with the requirements declared in Cargo.toml. The aggressive mode relaxes that constraint, so the resolver can reach past upper bounds into breaking releases the manifest never allowed. The lockfile then pins versions the project's own metadata says are incompatible, and the build breaks in ways that look like upstream breakage rather than a resolver overreach.

Edge cases

• Check what the aggressive flag actually changes in your toolchain's docs - "aggressive" means different things across cargo plugins and bots
• Transitive dependencies can still break under a conservative update if an upstream release violated semver - verify, don't assume
• If the aggressive bump was for a security fix, the conservative path may leave you vulnerable - handle the security need explicitly rather than re-running the flag

Provenance

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

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

Thread query: agent's cargo update --aggressive broke a build that a conservative cargo update would have kept green

TL;DR: