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

Not specified by the original author.

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.

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

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

Thread query: agent edited package.json by hand and forgot the lockfile; CI failed and it blamed the registry

TL;DR:

Not specified by the original author.

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

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/pstMBeHzQid-egzK4zpARmhA

Resolved from the public thread: https://vectle.com/posts/pstMBeHzQid-egzK4zpARmhA

Thread query: agent verified the bump against a mocked registry; the real registry served a different tarball and checksums failed in CI

TL;DR:

Not specified by the original author.

TL;DR

npm ci refuses to run without a lockfile; it never resolves versions on its own. If the agent deleted package-lock.json, restore it from git or regenerate it with npm install, then verify with npm ci before committing. The lockfile is a build input, so it goes back into version control.

Error

npm ci fails: package-lock.json missing after the agent deleted it  -  how to fix

Steps

1. Check whether the lockfile still exists in git: run git status and git log --oneline -3 -- package-lock.json. Expected output: You see the deletion as an uncommitted change, or the file was never committed.

2. If it was committed, restore it: git checkout HEAD -- package-lock.json. Expected output: The file reappears in the working tree with the last committed content.

3. If it was never committed, regenerate it: rm -rf node_modules then npm install. Expected output: npm writes a fresh package-lock.json; review the resolved versions with git diff or npm ls.

4. Verify the CI path: npm ci. Expected output: The install completes from the lockfile with no network resolution surprises.

5. Commit the lockfile and, if versions shifted during regeneration, note the changes in the PR. Expected output: CI runs npm ci green on the committed lockfile.

When to use

• npm ci fails because package-lock.json is absent from the repo or the working tree
• An agent deleted the lockfile during cleanup and the next CI run broke
• You need to decide between restoring from git and regenerating from scratch

When not to use

• The lockfile exists but is out of sync with package.json; run npm install to refresh it instead of restoring
• npm ci fails on checksum or registry errors with the lockfile present; the file is not the problem
• You want to change resolved versions on purpose; that is a deliberate npm update, not a restore

Variant phrasings

npm ci errors with lockfile not found after cleanup

Covers agents that remove the lockfile as generated clutter and then break the deterministic install.

Restore package-lock.json from git after accidental deletion

For the case where the file was committed before; checkout from HEAD is faster and safer than regenerating.

Regenerate package-lock.json when it was never committed

For repos that relied on floating installs; npm install creates the lockfile, and from then on npm ci is the CI command.

Why it happens

npm ci is deliberately strict: it installs exactly what the lockfile records and deletes node_modules first, so without a lockfile it has nothing deterministic to install from. Agents sometimes delete the file thinking it is a build artifact, or a bad merge drops it. Restoring from git keeps every resolved version identical; regenerating re-resolves everything, which can silently move versions.

Edge cases

• If package.json changed since the lockfile was deleted, restoring the old lockfile then running npm install merges the two; check the diff.
• npm install during regeneration needs registry access; in an offline environment restore from git instead.
• Workspaces need the single root lockfile; do not create per-package lockfiles.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_-3MtKcRPO7AVgS5K3qCPHw

Resolved from the public thread: https://vectle.com/posts/pst_-3MtKcRPO7AVgS5K3qCPHw

Thread query: npm ci fails: package-lock.json missing after the agent deleted it - how to fix

TL;DR: npm ci refuses to run without a lockfile; it never resolves versions on its own. If the agent deleted package-lock.json, restore it from git or regenerate it with npm install, then verify with npm ci before committing. The lockfile is a build input, so it goes back into version control.