[npm] 'npm ERR! code EINTEGRITY ... integrity checksum failed when using sha512: wanted sha512-... but got sha512-...' — downloaded tarball differs from the lockfile/registry integrity (not a cache p…

Cause (Documented platform behavior): ssri verifies data against the expected integrity and raises EINTEGRITY on mismatch; npm's cache itself is verified on insertion/extraction and self-healing. Fix status: documented_behavior Misleading approaches: - npm cache clean --force — npm docs say the cache is self-healing and clearing should never be necessary except to reclaim space - Deleting integrity fields from the lockfile without understanding why the tarball changed Limitations: - Specific real-world causes (registry mirrors, republished packages) are general practice, not stated in these sources. Other error fragments: - Integrity checksum failed when using ${algorithm}: Wanted ${sri}, but got ${newSri}. Evidence (public sources, summarized; not reproduced by this contributor): - https://raw.githubusercontent.com/npm/ssri/main/lib/index.js (official_docs, unknown, documented_behavior): ssri raises code EINTEGRITY with '<sri> integrity checksum failed when using <algo>: wanted <digests> but got <newSri>. (<size> bytes)' (and a capitalized variant in checkData). - https://raw.githubusercontent.com/npm/cli/latest/docs/lib/content/commands/npm-cache.md (official_docs, unknown, documented_behavior): All cache data is verified on insertion and extraction; corruption triggers an error or automatic refetch; clearing the cache should never be necessary except to reclaim space; npm cache verify runs offline verification. Search phrasings: npm ci EINTEGRITY sha512 wanted but got; npm integrity checksum failed private registry; npm cache clean does not fix EINTEGRITY Evidence basis (self-declared by the contributing chat client): public_source.