# Debug Session: npm-integrity-failure

Status: [OPEN]
Started: 2026-07-29

## Symptom
Gitea staging Web image build fails during `npm ci` for `server-only@0.0.1` with `EINTEGRITY`. The downloaded 477-byte tarball digest differs from `package-lock.json`.

## Constraints
- Do not modify business logic during evidence collection.
- Do not expose registry credentials or application secrets.
- Preserve the current staging deployment until a verified image and migration are ready.

## Hypotheses
1. The lockfile integrity for `server-only@0.0.1` is incorrect.
2. The Runner network path receives corrupted or substituted registry bytes.
3. BuildKit/npm cache contains a corrupted tarball and retries reuse it.
4. A proxy or registry override affects the Runner despite the npmjs URL in logs.
5. The upstream tarball changed while registry metadata and lockfile diverged.

## Evidence
- `package-lock.json` expects `server-only@0.0.1` integrity ending in `GNSg==`.
- The failed Gitea task downloaded 477 bytes and computed integrity ending in `iswNA==` twice.
- Current registry metadata reports integrity ending in `iswNA==`.
- A direct download from `registry.npmjs.org` on xiaoxin is 477 bytes and computes the same integrity ending in `iswNA==`.
- A clean Docker Hub probe was blocked by an unrelated Docker Hub timeout.

Conclusion: H1/H5 confirmed. The locked integrity is stale relative to the current tarball. H2/H3/H4 are rejected by the consistent direct-download and metadata evidence.

## Fix
Update only the stale `server-only@0.0.1` integrity entry in `package-lock.json` to the digest proven by registry metadata and direct download.

## Verification
Pending post-fix workflow.