[Mikola Lysenko (mikolalysenko)]

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

Fixes #1909

Summary

vendor fetches service downloads ahead of its main loop (plan_service_downloads), and decided which packages to plan with a hand-written copy of the loop's candidate checks. That copy drifted. It never saw the vlt preflight's refusals, so in a vlt project a package the loop refuses still got a download grant. A grant can start a server-side build and counts against quota. Refused cases include a store copy with bundleDependencies or build steps, a gitignored vendor dir, a member stray lock, or a route refusal.

Root cause

The candidate walk (fanning release-variant base purls out to their qualified records, once per base) and the per-candidate gates (ledger-entry-missing refusal, installed-variant probe, superseded-install stand-in, ambiguous variants, Bun refusal, vlt refusal, linked vendor dir) were written twice. They were written once in the loop and once in the plan, and only the loop's copy got the vlt refusal and the vendor_variant_ambiguous outcome.

Change (vendor.rs only)

• candidate_groups is the one candidate walk, used by both the plan and the loop.
• CandidateGates::judge returns one CandidateVerdict per candidate: Skip, Ambiguous, Refuse { code, detail } or Vendor { record, superseded }. The loop renders Ambiguous/Refuse exactly as before (same codes, details and matched/fetch_failed bookkeeping). The plan keeps only Vendor verdicts.
• The plan keeps its plan-only skips: a hosted takeover, an npm artifact the ledger anchors, and an in-sync re-run. The loop answers these without the service.
• UNINSTALLED_REL replaces four spellings of .socket/vendor/.uninstalled.
• The loop still judges against its live ledger copy (its per-package persists update it), so the ledger is passed per call, not stored in the gates. Ambiguous candidates are collected and joined to fetch_failed after the loop. Nothing reads fetch_failed in between, so the end result is the same.

Test evidence

Regression test plan_gate_tests::the_plan_leaves_out_a_package_the_vlt_preflight_refuses: a vlt project (vlt-lock.json + store copy) whose store package.json gains bundleDependencies. vlt_vendor_preflight_pairs refuses it with vendor_bundled_deps_unsupported and the plan must not include it.

• Red on main (same fixture, old plan signature): panicked with the vlt-refused package is never planned (the plan returned the uuid).
• Green on this branch.

Local runs on 539f228:

• cargo fmt --all -- --check: clean
• cargo clippy --workspace --all-features -- -D warnings: clean
• cargo test -p socket-patch-cli --lib commands::vendor: 75 passed
• cargo test --workspace --all-features --no-fail-fast: 236 targets OK. 13 failures in 4 targets, all environmental and outside this diff. 11 are permission-failure tests that cannot fail as root (the sandbox runs as uid 0): core copy_tree/vlt_heal/pypi_poetry/pypi_requirements, in_process_redirect, repair. 2 are e2e_bun_lockb tests that reach the live patch API (no network here; see Fix bun.lockb nightly e2e reaching the live blob API #1905).
• --include-ignored e2e: e2e_vendor_npm_build 43/43, e2e_vendor_pypi_build 57/57, e2e_vendor_bun_build 40/40, e2e_vendor_vlt_build 66/66 (vlt binary absent, so the real-vlt legs self-skip), e2e_vendor_gem_build 46/46.

Per-issue checklist

• vendor's download plan re-walks the vendor loop's candidate selection, and the copy skips the vlt refusal and the ambiguous-variant check #1909: vlt-refused candidate never planned (the_plan_leaves_out_a_package_the_vlt_preflight_refuses); ambiguous variants handled by the same verdict (the_plan_follows_the_ledger_pick_of_an_uninstalled_variant_group, variant_probe tests unchanged and green); const UNINSTALLED_REL added.

/code-review high findings not fixed here

• The dry-run takeover preview (takeover_dry_refusal) is passed pkg_source, not the superseded stand-in. This is pre-existing on main (unchanged line) and a separate behaviour question, so it's left for a follow-up.
• The plan's three plan-only skips stay in the plan: they describe where the loop answers without the service, not a refusal, so they have no loop twin to share.
• judge still hashes a representative file in both the plan and the loop. Main already did this, so this PR doesn't add the cost.

Related, not in scope: #1839 (one Bun + vlt refusal map across every vendored caller).

https://claude.ai/code/session_011f9aeS19dxVdN1MB6299Hy

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 539f228. Configure here.}

[Mikola Lysenko (mikolalysenko)]

[burn-down agent] Ready for review at 539f228.

• CI: 82/82 check runs on 539f228 green (success/skipped/neutral); no main-wide failures.
• Bugbot: reviewed 539f228, no findings; no open review threads.
• Mergeable, no conflicts with main; no CHANGELOG.md change.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Final review brief

What it does: Fixes #1909. vendor's download plan kept its own copy of the vendor loop's candidate checks, and that copy skipped the vlt preflight refusals. So in a vlt project, a package the loop would refuse could still get a download grant, which can start a server-side build and uses quota. The PR moves the checks into one CandidateGates::judge, which returns Skip / Ambiguous / Refuse / Vendor and is shared by the plan and the loop, so the two can't drift again.

Risk: low. This is an extraction inside one file. The checks run in the same order with the same error codes and details. The only behavior change is the intended one: the plan now leaves out vlt-refused candidates. Ambiguous candidates are now added to fetch_failed after the loop instead of during it. That is equivalent: nothing reads the set in between, and each candidate is in only one group.

Look here:

• vendor.rs:2877-2963: CandidateGates::judge, especially the Bun/vlt/linked-dir refusals at 2937-2957.
• vendor.rs:2972-3010: the reworked plan_service_downloads, with the plan-only hosted-pin skip at 3001.
• vendor.rs:3384-3396: the gates are built from the loop's real state.
• vendor.rs:4169: the delayed fetch_failed.extend(ambiguous).
• vendor.rs:5465: the regression test.

Verified:

• Traced old against new line by line.
• cargo test -p socket-patch-cli --lib commands::vendor: 75 passed.
• clippy (lib/bins, test profile): clean.
• Mutation checks:
  • Disabling the vlt gate makes the new test fail, so the test covers the fix.
  • Turning Ambiguous into Skip makes the existing variant-probe test fail.
• CHANGELOG.md is untouched.
• CI: ci-ok and clippy are green on the head.

Changes I made: None.

Open questions: None.

• No lib unit test covers the loop's own vlt refusal output; that gap predates this PR, and the e2e suites likely cover it.
• The dry-run takeover preview still gets pkg_source. This already happens on main, and the description flags it as a follow-up.

Auto-merge is armed: approving sends this straight to the merge queue.

---

Generated by Claude Code

[Wenxin Jiang (Wenxin-Jiang)]

[agent] Reviewed 539f228141aa937e428b9504eb6bbaea36131bf6. Checked shared candidate gates through vendor execution and service planning, variant ambiguity and vlt refusal ordering. No major correctness issues found. Validation: source and regression-test review plus the available exact-head CI checks; no local test pass is claimed.