renovate branch had a poetry.lock conflict with main; the agent deleted the lockfile and regenerated it, changing 200...

TL;DR: Restore the lockfile and regenerate it from the merged manifest instead of deleting it. Deleting poetry.lock and regenerating from scratch re-resolves all 200 packages, which is how a one-package conflict became a 200-version diff. Keep the file, merge the manifest, run the lock command, and confirm the diff stays small.

the agent deleted the lockfile and regenerated it, changing 200 versions

1. Restore poetry.lock from main (or the pre-conflict state).

Expected: the known-good lockfile with all 200 pins is back.

1. Apply only the intended version changes to pyproject.toml and resolve the manifest conflict by hand.

Expected: the manifest reflects exactly what the PR wanted, nothing more.

1. Regenerate the lockfile from the merged manifest with the lock command.

Expected: a minimal diff touching only the intended packages.

1. Inspect the diff: if it touches far more than the intended packages, stop and investigate before committing.

Expected: no 200-version surprise diffs reach review.

Use this when

• A poetry.lock conflict was "resolved" by deleting the file
• Regenerating the lockfile changed hundreds of versions unexpectedly
• The lockfile diff exploded far beyond the PR's intent
• "Deleted the lockfile and regenerated it" appears in the agent log

Not for this skill when

• The lockfile is genuinely corrupt and must be rebuilt from scratch
• The PR is an intended mass upgrade (then a big diff is expected and fine)
• The project uses pip requirements files rather than poetry

Variant phrasings

• poetry.lock deleted and regenerated
• poetry lock conflict changed 200 versions
• regenerated lockfile, huge unexpected diff
• poetry.lock merge gone wrong

Why it happens

The agent treated the lockfile as disposable build output, but it is a pinned record of 200 independent version decisions. Deleting it throws away every pin at once, and the resolver happily picks fresh versions for all of them. The conflict got "resolved" by discarding 200 decisions nobody asked to revisit.

Edge cases

• If the resolver picks newer versions than intended even from the merged manifest, tighten the ranges in pyproject.toml before locking.
• The lock command can be slow on big trees; that is fine, it is still cheaper than reviewing 200 version changes.
• Always commit the lockfile and the manifest together, never one without the other.

Provenance

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