GeezerVison

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

Fixes #541

Summary

After a vendored dependency was upgraded or uninstalled, every scan --mode vendored exited 1 (partial_failure / vendor_lock_entry_not_found) and told the user to run vlt install, which they already had. The documented reconcile, scan --prune, failed too: it exited 1 in the same run where it reverted the stale entry. Scheduled vendored scans stayed red after any routine upgrade.

With this change, a vendored rescan skips such an entry, prints a vendor_ledger_entry_unwired warning that points at scan --prune, and exits 0. --prune reverts the entry and exits 0. That holds even when the removed dependency was the project's last one.

Root cause

vendored_ledger_supplement (scan/discovery.rs) puts back into discovery every vendor-ledger entry that has no crawled counterpart. This exists for the fresh-clone case, where the committed artifact is the dependency. The function never checks whether the lock still wires the artifact. Once the dependency has left the lock, the vendor step tries to re-vendor a package the lock no longer has, and it does this before the prune GC runs. The bug is in shared code: npm package-lock projects hit it the same way.

Fix

• Filter at the shared boundary. The supplement now asks the lockfile in-use probe that the prune GC already reverts by (vendor::dispatch_in_use_one). An entry is supplemented only when the probe says it's in use or can't decide (None, fail-safe: no probe for the ecosystem, or no readable lock). Entries proven unwired come back in LedgerSupplement::unwired. get uses the same supplement and gets the same behavior.
• Warn, then reconcile. A run that won't prune reports the skipped entries in the run-level vendor_ledger_entry_unwired warning, naming the purls and pointing at scan --prune. Any non-hosted --prune run reverts them in its GC with no warning.
• Empty crawl. If the removed dependency was the last one, the crawl finds nothing. Until now the GC was skipped entirely there, because pruning the manifest against an empty crawl is destructive. --prune now still runs the vendored half of the GC (gc::run_vendor_only_gc, under the apply lock) whenever unwired entries exist. That half decides from the lockfile and manifest, not the crawl. The manifest prune is still skipped.
• CLI_CONTRACT.md documents the supplement rule, the warning code and the empty-crawl GC.
• Drift-kept entries (Bugbot, three rounds): npm can re-lock an uninstalled entry away, and then the prune GC drift-keeps it by design, so the warning comes back. The warning only recommends scan --prune, which reverts just the entries proven unwired. For a drift-kept entry it points at the prune's own GC: kept line. Both lock-edit remedies I tried were unsafe: one doesn't converge, and the other would unwire every vendored entry. Reclaiming such entries is the npm prune follow-up noted on Vendored vlt scan exits 1 after the patched dependency is upgraded or uninstalled, and even scan --prune exits 1 while it reverts the stale entry #541.

Tests (red on main, green here)

Test-harness notes:

• The real-vlt mock patch API now answers only for the purls a batch request asks about, as the production API does. Before, it offered the 1.3.0 patch to a project bumped to 1.2.0.
• On vlt 0.0.0-30 … 0.0.0-32, a dependency removed from package.json stays in the lock: vlt uninstall keeps a file: spec declared, and vlt install keeps the removed edge and node. socket-patch correctly keeps the entry there. I tested every supported release from 0.0.0-19 through rc.13, and those three are the only ones affected. The uninstall leg skips them under a new removed-dependency-stays-locked rule in docs/testing/vlt-compatibility.md, and the manifest is regenerated with check-vlt-legs.py --derive.

Local verification

• cargo clippy --workspace --all-features -- -D warnings: clean.
• e2e_vendor_vlt_build through check-vlt-legs: clean on vlt 0.0.0-30, 0.0.0-32, rc.14 and 1.2.0 (34/34). The new legs also pass on 0.0.0-19 … 0.0.0-29, rc.1/5/9/13, rc.32 and 1.0.4.
• On vlt 1.2.0: e2e_redirect_vlt_build 38/38, mode_migration_vlt 14/14, plus e2e_safety_vlt and e2e_vlt passing. scan_vendor_e2e passes 33/33.
• cargo test --workspace --all-features --no-fail-fast: 208 binaries pass. 12 tests in 4 binaries fail identically on origin/main, because the sandbox runs as root and their read-only-directory setups don't block writes. Those are covgap_commands_vendor (3), in_process_redirect (3), repair (2) and the socket-patch-core lib (4); this PR doesn't touch core.
• The *_production vlt legs can't run in this sandbox (the CLI's TLS roots reject the proxy's CA), so CI covers them.
• cargo fmt --all -- --check reports drift in 127 files on origin/main itself, and CI doesn't run fmt. I left the repo's formatting as is.

CI notes

• The PDM native (...) jobs fail one random cell per run against the live patch API, and the cell changes every time. This is the same flake PR Fix lock-only requirements.txt discovery (#412, #523) #530 cleared on a rerun; details are in the PR comments. I re-ran the failed jobs once.
• No wrapper (npm/, pypi/, gem/) changes are needed: they only dispatch to the binary.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VEgj84zEsgqYoVSqrt7CqJ

Generated by Claude Code