GeezerVison

LLM Description written by Claude Code:claude-opus-5-5

Fixes #1481

What users saw

Take an npm workspace where member a depends on registry
[email protected] and member b depends on a file: copy of the same
release, either a packed tarball or a source directory.
scan --mode hosted --vex pinned the registry entry and its in-run VEX
attested [email protected] not_affected. But npm installs b's copy
from its spec, so that copy stays unpatched. The tarball shape at least
warned. The directory shape warned about nothing. A standalone vex after
npm ci correctly refused both.

Root cause

The npm lock rewriter (patch/redirect/mod.rs) already handles copies it
can't redirect by recording the uuid in bundled_skipped_uuids, which
keeps the in-run VEX from assuming the patch applied. The bundled and
hasShrinkwrap branches do that. Two shapes did not:

• file: tarball: the non_registry branch warned
  redirect_npm_non_registry_entry_skipped but never recorded the uuid.
  Before Fix open npm issues #1008 the engine's attribution pass vetoed the pin. Since Fix open npm issues #1008
  it lets a shadowed pin through, so nothing stopped the attestation.
• file: directory: npm locks it as a versionless link entry
  plus the source directory's own entry, which carries the name and
  version. The rewriter matches on name@version and never saw the copy.

#1469 fixes the pnpm counterpart (#935) in the engine, but only for pnpm
locks. This PR fixes npm in the npm rewriter, so the two PRs don't
overlap.

Fix

• The non_registry branch records the uuid, like its bundled and
  shrinkwrap siblings.
• A versionless link entry that npm reached through a file: spec
  takes the identity of its source directory's entry. That entry's
  name, else its folder name with any @scope/ parent kept, as npm's
  nameFromFolder does. The existing link branch then warns
  redirect_npm_link_entry_skipped (its detail now says the copy stays
  UNPATCHED) and records the uuid.
• A plain workspace-member link is first-party source, not a copy, so it
  is left alone. It still reports redirect_npm_entry_not_found as
  before.
• The registry copy is still pinned. That keeps the existing npm and yarn
  classic policy: patch what can be patched, warn about the rest, and keep
  the in-run VEX out of it.

Tests (red → green)

The lock shapes in the tests are copied from a real npm 10.9.4
install-strategy=nested workspace install of the issue's repro.

tests/equivalence/npm_lock_rewrite.golden is re-blessed. Only the
output digests change, for the seeded cases with link or non-registry
entries, which now carry the recorded uuid and the new detail text. The
inputs are unchanged.

Run locally:

• cargo fmt --all -- --check: ok
• cargo clippy --workspace --all-features -- -D warnings: ok
• cargo test -p socket-patch-core --all-features --lib: 6420 passed.
  5 failed before the re-bless: the golden, plus 4 read-only-directory
  tests that can't fail when run as root in this container (copy_tree,
  vlt_heal, poetry/requirements write failure). They are unrelated to
  this diff.
• cargo test -p socket-patch-cli --all-features --test in_process_redirect --test e2e_vex_redirect --test in_process_redirect_pnpm:
  all pass except the same class of 3 root-only write-failure tests.
• A full cargo test --workspace ran out of this container's disk
  allowance, so CI is the record for the rest.
• e2e_redirect_npm_build -- --ignored (real npm 10.9.4, npm required):
  6 passed.

Review notes

/code-review high findings and what happened to each:

• The stale npm_link_entry_versioned_…_generic_not_found assertion and
  the workspace-member false positive: fixed by limiting link matching to
  links reached through a file: spec. The test still holds as written.
• Golden digests: re-blessed (see above).
• Scoped folder names: fixed, with a test.
• Not fixed: requiring the in-run VEX file to exist. When no statement
  survives, no VEX document is written, so that assertion would fail on
  correct behavior. The test keeps the same tolerant read as the existing
  bundled-copy test, and the registry-pin assertion proves the run
  reached the rewrite.
• Not fixed: bundled_skipped_uuids also exempts a uuid from the
  engine's contested-wiring veto. Since Fix open npm issues #1008 these shapes reach the
  engine as shadowed, not contested, so the pin was already written. This
  only adds the warning and the VEX demotion. Bundled and shrinkwrap
  copies already behave this way.
• Follow-up, not fixed here: link identity in shared code. Lockfile
  discovery (vex/discover/npm.rs) and the vendored npm backend still
  skip a versionless file: directory link. A standalone vex doesn't
  attest the issue's directory shape (it reports not_applied), so this
  PR keeps the fix in the rewriter. Moving link identity into the shared
  npm_lock_entries walk would touch every consumer, so it should be its
  own change.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RFYJv8oyp5Fz9ySBaorZcd

Generated by Claude Code