[Mikola Lysenko (mikolalysenko)]

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

Fixes #1850

Summary

On a project that is already vendored, scan --mode vendored --dry-run and
get <uuid> --mode vendored --dry-run said "Would download and vendor N
patches", while the same preview's --json (skipped /
already_vendored) and the wet run ("already vendored; nothing to do")
both said there was nothing to do.

Now the human preview matches them:

[dry-run] Would download and vendor 0 of 1 patch (1 already vendored). No changes made.
  [skip] pkg:npm/left-pad@1.3.0 (already vendored)      <- stderr, the wet run's line

Mixed runs list only the non-zero clauses, e.g. 1 of 4 patches (2 already vendored, 1 would be refused).

Root cause

preview_vendor already classified each row (PreviewVerdict::AlreadyVendored)
and the JSON arm recorded it, but the human renderer ignored the verdict:
render::dry_run_line subtracted only would-refuse rows, print_refusals
printed nothing for in-sync rows, and get used its own
format_dry_run(…, selected.len()) that subtracted nothing at all.

Fix

• render::Plan::Vendor { total, refused, in_sync }: the headline leaves
  out in-sync and refused rows.
• VendorPreview::print_human() prints the headline, the [skip] … (already vendored) lines (via the wet run's format_record_skip, on
  stderr like the wet run), the [would-refuse] lines and the symlink
  advisories. scan and get both call it, so they can't drift. Side
  effect: get --mode vendored --dry-run now also leaves refused patches
  out of its count, as scan already did.
• CLI_CONTRACT.md documents the headline.

No wrapper changes needed (npm/, pypi/, gem/ only dispatch to the binary).

Tests (red → green)

Issue	Test	Without fix	With fix
#1850 (scan)	tests/scan/scan_render.rs::scan_human_vendored_dry_run_skips_already_vendored	FAILED (Would download and vendor 1 patch)	ok
#1850 (get)	tests/get/get_render.rs::human_vendored_uuid_dry_run_skips_already_vendored	FAILED	ok
#1850 (shared headline)	scan::vendor_flow::preview_tests::preview_headline_leaves_out_already_vendored, scan::render::tests::dry_run_line_counts_already_vendored	n/a (new API)	ok

Updated tests/vendor/in_process_vendor_bun.rs::dry_run_human_names_would_refuse_records
to expect the shared headline (0 of 1 patch (1 would be refused)).

Commands run locally:

• cargo fmt --all -- --check: clean
• cargo clippy --workspace --all-features -- -D warnings: clean
• cargo test -p socket-patch-cli --all-features --lib: 942 passed
• cargo test -p socket-patch-cli --all-features --test scan --test get --test vendor: 248 / 174 / 151 passed
• The full cargo test --workspace --all-features build ran out of this
  container's disk while linking; CI covers the rest.

Review notes (/code-review high)

• Fixed: the stale Bun dry-run expectation; folded the counts into
  Plan::Vendor and the two print calls into print_human().
• Not changed: the preview marks a row AlreadyVendored whenever the
  ledger holds the purl at the same uuid, even for a legacy non-detached
  entry or one whose artifact was deleted, which the wet run would
  re-download or rebuild. That classification predates this PR and the
  JSON preview already reports those rows as already_vendored. This PR
  only makes the human output agree with it. Making the classifier check
  artifact and wiring would be a separate change.

---

Note

Low Risk
Human output and contract documentation only; JSON preview semantics were already correct and wet-run behavior is unchanged.

Overview
Fixes #1850: human scan --mode vendored --dry-run and get --mode vendored --dry-run no longer claim they would download and vendor patches that are already in the vendor ledger at the selected uuid.

The shared VendorPreview::print_human() path now prints a headline built from Plan::Vendor { total, refused, in_sync } (e.g. Would download and vendor 0 of 1 patch (1 already vendored)), emits [skip] … (already vendored) on stderr like the wet run, then the existing [would-refuse] lines. get stops using its own generic dry-run count and delegates to the same renderer as scan, so refused rows stay out of the headline there too. CLI_CONTRACT.md documents the headline behavior.

^{Reviewed by Cursor Bugbot for commit 6cb6fb1. Configure here.}

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

Burn-down agent: labeled Ready for review at 015ca581d4f2578fbf10c529f9cfddb9be9efe96.

• CI: 32/32 run checks green (50 skipped), mergeable, no conflicts.
• Bugbot: reviewed 015ca58, no findings; no open threads.
• Reviewer note: changes the --dry-run count for vendored patches already in sync (Vendored scan / get --dry-run on an already-vendored npm project says it "Would download and vendor N patches", while its own JSON and the wet run say there is nothing to do #1850); CLI_CONTRACT.md is updated with it, so check the wording there matches the new output.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Final review brief

What it does: Before this PR, scan --mode vendored --dry-run and get --mode vendored --dry-run counted patches that were already vendored as work, so an in-sync project was told it would "vendor N patches". Both commands now share one VendorPreview::print_human(). Its headline counts only real work (Would download and vendor K of N (A already vendored, R would be refused)), and it prints the wet run's [skip] <purl> (already vendored) line for each in-sync row.

Risk: low. Only the human dry-run output changes. JSON output, exit codes and the wet path are unchanged. A row gets exactly one verdict, and refusal is checked before already-vendored, so total - refused - in_sync can't double-count. The intended behaviour change is that get's headline now also leaves refused patches out, and the Bun test was updated to match.

Look here:

• scan/vendor_flow.rs:153-195:`` in_sync_count, `dry_run_line`, `print_human`
• scan/render.rs:267-294:``` the new Plan::Vendor{total,refused,in_sync} headline
• scan/mod.rs:3435-3441 and get.rs:2303: the two callers
• tests/scan/scan_render.rs:683 and tests/get/get_render.rs:112: end-to-end tests. Both fail on main, and the scan test also checks the ledger bytes are unchanged.

Verified: I read the full diff against #1850. The tests would fail without the fix. There is no debug code or scope creep, CHANGELOG.md is untouched, and there are no path or CRLF concerns because the change is formatting only. CI is green on 015ca58 (32 passed, 50 skipped, ci-ok and clippy both green). Bugbot found no new issues.

Changes I made: none.

Open questions (non-blocking, follow-up material): The human scan "Patches to vendor:" table above the headline still lists in-sync patches (scan/mod.rs around line 3366). The [skip] lines go to stderr while the headline goes to stdout, which matches the wet run.

Auto-merge (squash) is armed, so approving sends this straight to the merge queue.

---

Generated by Claude Code

[Wenxin Jiang (Wenxin-Jiang)]

[agent] Reviewed 015ca581d4f2578fbf10c529f9cfddb9be9efe96. Checked vendored dry-run counts and rows against AlreadyVendored/refused verdicts for scan and get, including mixed previews. No major correctness issues found. Validation: source and regression-test review plus the available exact-head CI checks; no local test pass is claimed.

[Mikola Lysenko (mikolalysenko)]

[final reviewer] Auto-merge was armed and the PR was approved, green and mergeable, but GitHub had never put it in the merge queue. I disabled auto-merge and armed it again, and it went into the queue at once.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

[agent] Dequeued because e2e-build failed to compile on the queue branch: preview_headline_leaves_out_already_vendored called preview_vendor, which main (#1930) split into preview_vendor (from the run's args) and preview_vendor_with (from explicit paths). Merged main and pointed the test at preview_vendor_with in 6cb6fb1. Locally: clippy clean; lib 869, scan 248, get 174, vendor 158 passed.

---

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 6cb6fb1. Configure here.}

[Mikola Lysenko (mikolalysenko)]

[final reviewer] Re-enqueued: approved, ci-ok and clippy green on the current head, mergeable, and no unresolved threads. The earlier eviction made GitHub turn off auto-merge, so I armed it again (squash) and the PR went straight back into the merge queue. The approval still counts after the post-approval commits.

---

Generated by Claude Code