agent's rollback commit reverted the lockfile but not the source change that depended on the new API

TL;DR: A rollback must revert the lockfile AND every source change made for the new version, together. Reverting only the lockfile leaves code calling APIs that no longer exist. Find the non-lockfile files in the upgrade commit, restore them to their pre-upgrade state in a follow-up commit, then reinstall and re-verify.

agent's rollback commit reverted the lockfile but not the source change that depended on the new API

1. List everything the upgrade commit changed: git show --stat [UPGRADE-COMMIT]. Expected: source files plus the lockfile - note the non-lockfile paths.
2. List what the rollback commit changed: git show --stat [ROLLBACK-COMMIT]. Expected: only the lockfile, confirming the rollback was partial.
3. Restore the source files to their pre-upgrade state: git checkout [PRE-UPGRADE-SHA] -- [those source paths], then commit as the rollback completion. Expected: git status shows the source files restored and the diff against pre-upgrade is empty for both code and lockfile.
4. Reinstall from the restored lockfile and run the smoke tests. Expected: install succeeds and tests pass - no references to new-version APIs remain.
5. Fix the runbook: the agent's rollback procedure must revert the upgrade PR's full diff, never just the lockfile. Expected: future rollback checklists list both file sets explicitly.

Use this when

• A rollback left the build broken after the lockfile was reverted
• Post-rollback errors reference APIs from the newer version
• The rollback commit touches only the lockfile
• You need a rollback completeness check for agent runbooks

Not for this skill when

• The rollback already covered code and lockfile together
• You are keeping the new version and fixing forward instead of rolling back
• The upgrade was lockfile-only with no source changes

Variant phrasings

• Reverted the lockfile but the code still uses the new API
• Partial rollback broke the build
• Rollback missed the source changes
• Incomplete revert after failed upgrade

Why it happens

Upgrade PRs routinely touch source alongside the lockfile: new API usage, migration shims, config changes. An agent that models "rollback = restore lockfile" reverts half the change. The remaining code calls functions that do not exist in the restored old version, and the failure surfaces as a build or import error that looks like a registry or toolchain problem instead of an incomplete revert.

Edge cases

• Database migrations need down-migrations too - code plus lockfile is not the whole story when schema changed
• Monorepos with nested lockfiles need the same full-diff treatment per workspace
• If a later commit built on top of the new API, reverting source may conflict - prefer a forward fix in that case

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_p-a7WoiGkmsAyx8i1GIhIQ