The git-hosted tarball fetcher dropped the integrity computed during
download, so the lockfile only stored the codeload.github.com / gitlab /
bitbucket URL. A compromised git host or MITM could then serve a
different tarball on subsequent installs without lockfile changes.

Propagate the SHA-512 SRI of the raw tarball back to the lockfile so the
worker validates it on every fresh fetch and rejects tampered tarballs
with TarballIntegrityError.

---
Written by an agent (Claude Code, claude-opus-4-7).

The previous deadbeef… literal was 128 hex chars stuffed after `sha512-`
which doesn't match the SRI shape pnpm actually emits (88 base64 chars).
Replace it with a real (but mismatched) sha512 base64 string so the
fixture mirrors what a tampered lockfile entry would look like.

---
Written by an agent (Claude Code, claude-opus-4-7).

…tarballs

The carve-out that kept git-hosted tarballs on gitHostedStoreIndexKey
even when the lockfile carried integrity made the writer disagree with
every other reader: pkg-finder, store status, the FUSE mounter, and
rebuild --skip-if-has-side-effects-cache all derive the index path from
storeIndexKey(integrity, pkgId). Lockfile entries with integrity would
silently miss the cached package and side-effects builds would
re-run (potentially landing under a second key).

Drop the carve-out and use the integrity-based key consistently. First
install after upgrading still re-fetches once (the old store entry is
under the gitHosted key), but the cafs deduplicates the underlying file
content, and subsequent installs reuse the entry like every other
tarball.

---
Written by an agent (Claude Code, claude-opus-4-7).

Two cases surfaced by the latest reviewer round:

1) FUSE handler crashed with a non-null assertion on integrity for
   pre-CVE-fix lockfiles that don't carry integrity for git-hosted
   tarballs. Fall back to gitHostedStoreIndexKey so the daemon can
   still serve those packages.

2) Once a lockfile committed by a newer pnpm carries integrity,
   getFilesIndexFilePath probes only storeIndexKey(integrity, pkgId).
   An older local store may still have the entry under
   gitHostedStoreIndexKey, so the install would refetch — and in
   offline mode hard-fail with NO_OFFLINE_TARBALL — even though the
   tarball is already on disk. Plumb the StoreIndex into the
   package-requester and migrate the entry to the integrity key on
   the fly when we detect this state.

Both fallbacks are tagged TODO(v12): once v12 forces lockfile
regeneration and any pnpm v11-written store will already have the
integrity-keyed entry, this bridging code can be removed.

---
Written by an agent (Claude Code, claude-opus-4-7).

…checks

The migration block that copies a git-hosted tarball entry from the
legacy gitHostedStoreIndexKey to storeIndexKey(integrity, pkgId) was
calling storeIndex.has() on every fetch, including all npm-registry
packages it has no business probing — a SELECT per package, multiplied
across thousands of dependencies.

Reorder so the URL prefix check (isGitHostedPkgUrl) and the integrity
presence check run first, and the SQLite lookup only runs for
git-hosted resolutions with integrity in the lockfile. Same migration
behaviour, ~zero overhead on the hot path.

---
Written by an agent (Claude Code, claude-opus-4-7).

A v10/v11 lockfile that doesn't yet record integrity will keep working
fine: the resolver returns no integrity, getFilesIndexFilePath falls
back to gitHostedStoreIndexKey, and readPkgFromCafs still finds the
cached entry. The migration only mattered for one specific case — a
v11-written lockfile (with integrity) landing on top of a stale v10
store — and the cost of dropping it is one extra HTTP fetch per
git-hosted package, once. The fetcher's dual-write then registers the
entry under both keys, so subsequent installs are cache hits.

Trade-off: `pnpm install --offline` on a stale v10 store immediately
after upgrading would fail with NO_OFFLINE_TARBALL for git deps until
an online run warms the cache under the integrity key. That's narrow
enough that keeping a permanent state-mutating shim in the hot fetch
path isn't worth it.

Removes the optional StoreIndex parameter on createPackageRequester
and the wiring through fetchToStore that existed solely for this.

---
Written by an agent (Claude Code, claude-opus-4-7).

…alias

Reviewer flagged that storeIndexKey(integrity, pkgId) collapses the
built/not-built dimension that gitHostedStoreIndexKey carries. Toggling
ignoreScripts between installs would let one variant overwrite the
other and a later install with the opposite setting would silently
read the wrong cached content.

Switch the design so git-hosted resolutions are addressed by
gitHostedStoreIndexKey(pkgId, { built }) consistently:

- Writer (getFilesIndexFilePath): detect git-hosted via tarball URL
  prefix and skip the integrity-key fast path; fall through to
  gitHostedStoreIndexKey regardless of whether integrity is present.
- Fetcher: drop the dual-write (no more storeIndexKey alias) and the
  pkgId field on FetchOptions that only existed for it.
- Readers (pkg-finder, modules-mounter/daemon, building/after-install):
  detect git-hosted via tarball URL and route to gitHostedStoreIndexKey.

The lockfile still pins integrity for security and the worker still
validates it on download — that part of the security fix is unchanged.

The FUSE TODO(v12) fallback that compensated for missing-integrity
lockfiles is gone — git-hosted is now keyed the same way regardless
of integrity, so there's no upgrade-only branch to clean up later.

---
Written by an agent (Claude Code, claude-opus-4-7).

---
Written by an agent (Claude Code, claude-opus-4-7).

Two more readers Copilot flagged that needed the same git-hosted
detection used by pkg-finder / FUSE / after-install:

- store/commands/src/store/storeStatus/index.ts: when checking whether
  the store has the index entry for a lockfile-listed package, was using
  storeIndexKey(integrity, id) whenever integrity was present. With
  git-hosted now carrying integrity in the lockfile, those entries would
  never be found.
- installing/deps-installer/src/install/index.ts (agent-mode store
  controller wrapper): same shape — bypassed the regular store
  controller for any package with integrity, which would skip the
  fallback for git-hosted packages whose actual cached entry is keyed by
  gitHostedStoreIndexKey.

Both now detect git-hosted via the tarball URL prefix and either route
to gitHostedStoreIndexKey (storeStatus) or fall through to the regular
store controller (deps-installer agent path).

Also:
- Updated the readPackageFileMap docstring in pkg-finder to document
  the git-hosted exception explicitly (was implying every
  with-integrity package is keyed by integrity).
- Expanded the changeset to include @pnpm/building.after-install,
  @pnpm/installing.deps-installer, @pnpm/modules-mounter.daemon,
  @pnpm/store.commands, and @pnpm/store.pkg-finder so all touched
  published packages get a patch bump.

---
Written by an agent (Claude Code, claude-opus-4-7).

Six call sites repeated the same shape:

  resolution.gitHosted
    ? gitHostedStoreIndexKey(pkgId, { built })
    : storeIndexKey(resolution.integrity!, pkgId)

Hoist it to @pnpm/store.index next to the two key functions, behind a
single helper that takes the resolution shape and the desired `built`
flag. The helper also folds in the legacy fallback (no integrity, no
gitHosted → gitHostedStoreIndexKey).

Each consumer collapses from a 3-5 line conditional to a one-liner:

  pickStoreIndexKey(resolution, pkgId, { built })

Touched: package-requester (writer), pkg-finder, FUSE daemon,
after-install (both side-effects-cache lookup and write), and
storeStatus.

---
Written by an agent (Claude Code, claude-opus-4-7).