# TL;DR

Re-resolve the lockfile against the real registry and stop treating mock-registry checksums as authoritative. Delete the lockfile entries the mock produced, run `npm install` pointed at the real registry, and confirm CI passes. A mocked registry can serve different tarballs (repacked, proxied, stale), so hashes recorded against it are meaningless for the real world.

## Error

```text
agent verified the bump against a mocked registry; the real registry served a different tarball and checksums failed in CI
```

## Steps

1. Confirm which registry each side used. Run `npm config get registry` in the agent's environment and in CI. Expected: the agent points at a mock or local mirror while CI points at the real registry.
2. Check what the mock served. Compare the tarball the mock returns with the real one, or just note that integrity fields differ. Expected: the hashes in the lockfile match the mock's tarballs, not the registry's.
3. Re-resolve against the real registry. Remove node_modules and the lockfile, point at the real registry, and run `npm install`. Expected: fresh integrity hashes recorded from the real tarballs.
4. Run the full verification in CI. Push and let CI install from the new lockfile. Expected: install succeeds with no checksum errors.
5. Fix the agent's process. Verification that asserts checksums must run against the real registry (or a byte-identical mirror); the mock is fine for API-shape tests but never for integrity. Expected: a documented rule the agent follows on every future bump.

## Use this when

- CI fails with integrity or checksum errors but the agent's local install was clean
- The agent tests against a mocked or stubbed registry
- Lockfile hashes were recorded in one environment and fail in another
- You use a registry proxy or mirror and suspect it serves altered tarballs

## Not for this skill when

- Checksums fail because the lockfile is simply stale - regenerate it normally
- The registry itself is compromised - that is a security incident, treat it as one
- The failure is a 404 or version-not-found, not a hash mismatch

## Variant phrasings

- npm ERR code EINTEGRITY after mocked registry test
- checksum mismatch between test registry and production registry
- lockfile integrity fails in CI but not locally
- agent tested against a fake registry

## Why it happens

Integrity hashes in the lockfile are hashes of the exact tarball bytes. Mock registries often serve repacked or hand-built tarballs whose bytes differ from the published ones, even when the contents are equivalent. The agent records the mock's hashes, CI downloads the real tarballs, the bytes differ, and the install fails. The agent did everything right except trusting the wrong source of truth.

## Edge cases

- Registry proxies that re-sign or repack tarballs cause the same failure - verify your mirror serves byte-identical tarballs before trusting its hashes.
- If you must verify offline, record which registry the hashes came from in the PR description so reviewers know the provenance.
- Partial fixes (deleting only the failing entries) can leave a mix of mock and real hashes - a clean re-resolve is safer.
- Some mocks serve tarballs with different metadata ordering; the contents look identical but the bytes differ, so eyeballing the diff will not catch it.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_MBeHzQid-e_gzK4zpARmhA