TL;DR: Never hand-edit the manifest without regenerating the lockfile in the same change. Redo the bump with the package manager's own command so both files update together, and add a CI check that fails when the lockfile is out of sync. The registry was never the problem - the tree CI installed did not match the manifest the agent wrote.

```text
agent edited package.json by hand and forgot the lockfile; CI failed and it blamed the registry
```

1. Confirm the desync: compare the version in package.json against the locked version in package-lock.json. Expected: they differ - the lockfile still pins the old version.
2. Regenerate properly: revert the hand edit and redo it with the package manager (`npm install [pkg]@[version]`), which updates both files atomically. Expected: manifest and lockfile agree on the version.
3. Push and watch CI. Expected: the supposed "registry" failure disappears.
4. Add a sync check to CI - an install-from-lockfile step fails on desync, or add an explicit lockfile-check job. Expected: future hand edits fail fast with a clear desync message instead of a misleading install error.
5. Teach the agent: manifest edits go through the package manager CLI, never a text edit. Expected: the agent's runbook lists the CLI command, not a file edit.

## Use this when
- CI failed after a manifest hand-edit
- The lockfile and manifest disagree on a version
- The agent blamed the registry for what is a local desync
- You need a lockfile-sync gate in CI

## Not for this skill when
- It is a genuine registry outage - check the registry status page first
- The conflict is a lockfile merge conflict from two branches
- The lockfile was edited intentionally via the package manager

## Variant phrasings
- Edited package.json forgot package-lock
- Lockfile out of sync after hand edit
- CI failed, blamed registry
- Manifest lockfile mismatch

## Why it happens
Install-from-lockfile commands install exactly what the lockfile says and error when the manifest disagrees. The agent edited the manifest as text, treating the lockfile as a build artifact that refreshes itself. The resulting error surfaces at install time, which looks like a registry problem, when it is really a local desync between the two files.

## Edge cases
- Plain `npm install` (not the CI variant) silently "fixes" the desync by rewriting the lockfile - in CI always use the lockfile-strict install
- Monorepos have multiple lockfiles and all of them must stay in sync
- The misleading error can occasionally be a real proxy or cache issue - verify the desync first before concluding

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ERfT70AXz4TC6xGLZw-rSw