GeezerVison

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

Fixes #900

Root cause

Discovery::vendor_entry_live returns a bare bool. It is false in three different situations:

1. Contested. Another lock resolves the same version from elsewhere, e.g. package-lock.json resolving from the registry beside a wired yarn.lock / bun.lock. contest_across_locks dropped the ref and kept only a diagnostic.
2. Removed. The dependency left the lock (npm uninstall or an upgrade).
3. Wiring dropped. A relock dropped the .socket/vendor/ reference, but the package is still in the lock.

vendor --check always printed the case-3 text: "no lockfile or config references … any more, so a fresh install gets the unpatched package; re-run socket-patch vendor to rewire it". In cases 1 and 2 that text is false, and vendor, scan and repair are all no-ops, so the CI gate stayed red for good. vex added the same "no lockfile or config wires it" phrase after its correct patched_ref_unattributable warning.

Fix

• Core (vex/discover/mod.rs)
  • Discovery now keeps the refs it drops as contested (contested: Vec<ContestedRef>, recorded in contest_across_locks).
  • New Discovery::vendored_contest(purl, uuid) returns the contest that killed a vendored claim.
  • New Discovery::resolves_package(purl) says whether any lock resolves the package at all.
  • The golden renderer covers the new field. One golden gained a contested entry: the existing package-lock vs vlt-lock contest fixture.
• vendor --check (commands/vendor.rs, unwired_check_failure)
  • Contested: reports wiring contested: <lock> wires .socket/vendor/<eco>/<uuid>, but <other> resolves the same version from elsewhere …; delete whichever of the two locks the project does not install from. It still fails, because an install from the other lock is unpatched.
  • Removed (npm and PyPI only, because only those extractors record every lock entry): when no lock resolves the package and the prune GC's in-use probe answers Some(false), it reports dependency removed: no lockfile resolves <purl> any more …; run socket-patch scan --mode vendored --prune. vendor --check fails a vendored package whose lock is contested by a sibling package-lock.json with "no lockfile or config references .socket/vendor/… any more", which is false, and its remedy ("re-run socket-patch vendor") is a no-op, so the check stays red forever #900 verified that remedy, and it matches scan's own vendor_ledger_entry_unwired hint.
  • Anything else keeps the existing text.
• vex: the vendor_unwired phrase no longer claims nothing wires the artifact. It names the three causes, so it no longer contradicts the contest warning printed just before it. The reason code is unchanged.
• CLI_CONTRACT.md: the vendor --check section documents the two new reasons.
• The npm, PyPI and gem wrappers only dispatch to the binary, so they need no change.
• Ported c831b63: a cherry-pick of Route Gradle digests through utils::digest #878's 659ac2c, which fixes main's red utils::digest guard test. It becomes a no-op once Route Gradle digests through utils::digest #878 lands. See the PR comment.

Tests (red → green)

The existing vendor_check_fails_when_lock_no_longer_wires_artifact test (#725, case 3) still passes, with its message unchanged.

Local runs:

• cargo clippy --workspace --all-features -- -D warnings: clean.
• cargo test --workspace --all-features --no-fail-fast: everything passes except 12 permission-denial / unwritable-file tests, all in files this PR doesn't touch. They fail because this sandbox runs as root, where chmod 0o555 doesn't block writes. The same 12 fail identically on unmodified main 9c43dfc in the same container: 4 in core --lib, 3 each in covgap_commands_vendor and in_process_redirect, and 2 in repair. CI runs as a non-root user.
• cargo fmt: only the hunks this PR touches are formatted. main isn't rustfmt-clean under the pinned 1.93.1 toolchain (123 files differ), and CI has no fmt gate, so unrelated files are left alone.

CI: every check on c831b63 is green, including gradle 8.14.3 / jdk 21 / vendor / windows-latest. That job failed the first time on a Maven Central HTTP 403 and passed when re-run once. Bugbot's review of c831b63 found no issues.

Follow-ups

• After an uninstall, npm 8 (lockfileVersion 2) drops resolved from the legacy mirror. That's Vendored npm vex and vendor --check fail after any npm 7–10 npm install on a lockfileVersion 2 lock, because npm drops resolved from the legacy mirror and #813 treats that as an unpatched npm 6 install (regression) #879's root cause and out of scope here.

🤖 Generated with Claude Code

https://claude.ai/code/session_01U5HBJbvvfmhkxErLkvp4rP

Generated by Claude Code