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.

```text
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