GeezerVison

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

Fixes #325

Summary

If a lock rewires name@version to a Socket patch and another package also bundles that same name@version, vex and scan --vex no longer attest it not_affected. The bundled copy is inBundle: true in v2/v3 locks or bundled: true in v1. npm unpacks it from the parent's tarball, so no rewire reaches it and it stays unpatched. The reference is now reported as patched_ref_unattributable, the warning names the bundled copy's lock location, and the reference isn't attested. That matches how the contract already treats "another lock resolves the same name@version from a non-Socket source".

Changes:

• vendor/lock_inventory/npm.rs: the shared npm lock walk is split on the bundled flag. npm_lock_nodes is unchanged. The new npm_lock_bundled_nodes returns the bundled entries with their location: the packages key, or the >-joined v1 dependency chain.
• vex/discover/npm.rs: each npm lock records its bundled purls, and push_uncontested drops any ref whose purl has a bundled copy in either lock of the npm pair. Bundled copies also count as resolved_elsewhere, so they contest the same version in other lock types too. The dropped uuid stays recognized, so a matching ledger record is dead as well (redirect_unwired / vendor_unwired), under --no-verify too.
• Docs: a CHANGELOG Fixed entry, and the CLI_CONTRACT "Contested locks" rule.

Root cause

npm_lock_nodes skips bundled entries, which is correct for the rewriters. That meant VEX discovery never saw the unpatched bundled copy. contest_across_locks only contests refs from a different file, so the hoisted rewired entry was attested even though the same run warned *_bundled_instance_skipped ("that copy stays UNPATCHED").

Test evidence

The in-run scan --vex goes through the same generator (generate_vex_from_manifest_path, which calls discover_wiring), so it shares the gate. The hosted post-install cell already omitted the purl on main, and it still does.

Red was shown by stashing the two core source files and re-running the new tests against main's implementation.

• cargo test -p socket-patch-core --all-features --lib -- vex::discover lock_inventory: 435 passed.
• SOCKET_PATCH_NPM_E2E_REQUIRED=1 cargo test -p socket-patch-cli --all-features --test e2e_redirect_npm_build -- --ignored (real npm 10, Node 22): 5 passed.
• cargo test -p socket-patch-cli --all-features --test e2e_vendor_npm_build -- --include-ignored: 14 passed.
• cargo clippy --workspace --all-features -- -D warnings: clean.
• cargo fmt --all -- --check: the new code is rustfmt-clean. The remaining diffs are already on main, in files and hunks this PR doesn't touch.
• cargo test --workspace --all-features --no-fail-fast: 10,397 passed and 22 failed. The 22 are the same sandbox-only set reported on Fix #258: state the real Maven Trusted Checksums floor #322 and Fix Poetry venv discovery to match Poetry (#327, #329) #330: write-failure and permission tests that fail because the sandbox runs as root, plus the peak-RSS stage_local_artifact_caps_oversized_artifact_before_buffering. None of them are in VEX or npm code.
• The npm, PyPI and gem wrappers only dispatch, so they need no change.
• CI on 2aa1f21: green. All checks pass. On attempt 1, test-release and test (windows-latest) failed in suites this PR doesn't touch (vendor_gem_lockfile_only_e2e and update_notifier_e2e; see the comment above). Both passed on their single rerun.

Follow-up (not needed for #325)

The vendored out-of-sync probe in vex/verify.rs still checks only the one package_paths copy for each purl. With this change, a bundled copy can no longer produce an attestation. The other duplicates of the same version are ordinary nested entries, and the vendor backend rewires all of those. So the single-copy probe only limits how complete the vendored_tree_out_of_sync warning is, not whether the attestation is correct.

Separately, vendor_gem_lockfile_only_e2e's dead_endpoint() releases its port before use, so tests running in parallel can race for it. The comment above proposes a fix for its own PR.

🤖 Generated with Claude Code

https://claude.ai/code/session_01BAB2TPeepsb616tuH3Nd3S

Generated by Claude Code