GeezerVison

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

Fixes #489

Summary

A global run (-g / --global-prefix) started inside a vendored NuGet project
no longer takes over, or unpatches, the project's own installed copy.

Root cause

project_state_in_scope treats a global run's target as separate from the
cwd project's install. For NuGet that's wrong: a PackageReference project
restores into the global packages folder (~/.nuget/packages or
NUGET_PACKAGES), so the "global copy" of a package the project vendors is
the project's patched install. Since #446:

• scan -g --mode agent and apply -g took that copy over as an agent patch;
• rollback -g and remove -g restored upstream bytes into it.

dotnet restore --locked-mode never re-extracts it, because the lock and the
nupkg's sha512 still match. So the project built unpatched with exit 0
everywhere while vex kept attesting not_affected.

Fix

• NuGetCrawler::global_roots_shared_with (core) says whether the global run's
  NuGet folder is one the project restores into. It uses the packageFolders
  its restores recorded, plus the global folder while some project has no
  restore yet. It needs no root-level .NET marker.
• commands::vendor_owned_keys (CLI) is the single ownership rule. In project
  scope the whole ledger owns. Under global scope only the ledger's NuGet keys
  own, and only when that folder is shared and --ecosystems selects nuget.
• scan, apply (both paths, including --check), rollback and remove use it:
  • scan skips the copy as vendored and adds vendored_ownership_retained;
  • apply skips it as vendored;
  • rollback and remove leave it patched and report a skipped / vendored
    event plus a human [skip] line;
  • rollback keeps its manifest record.
• Every other ecosystem, and any NuGet store the project doesn't restore into
  (such as RestorePackagesPath), keeps Fix -g touching the cwd project's state (#436, #445) #446's behavior.
• CLI_CONTRACT.md documents the exception.

Out of scope

The hosted variant (from a comment on #489) predates #446. Agent mode
doesn't yield to hosted pins even in project scope, so fixing it needs a
contract decision on a new skip reason. I split it into #1793.

Test evidence

Red on main, green on this branch:

Commands run locally:

• cargo fmt --all -- --check: ok.
• cargo clippy --workspace --all-features -- -D warnings: ok.
• cargo test -p socket-patch-cli --all-features --test global_scope_project_state: 47 passed.
• SOCKET_PATCH_DOTNET_E2E_REQUIRED=1 SOCKET_PATCH_DOTNET_E2E_VERSION=8 cargo test -p socket-patch-cli --all-features --test e2e_nuget_dotnet_build -- --ignored: 4 passed.
• cargo test -p socket-patch-cli --all-features --test e2e_nuget -- --include-ignored: 22 passed.
• cargo test --workspace --all-features --no-fail-fast: 11 failures, all outside this change.
  • They are identical before and after this branch's review fixes.
  • The sandbox runs as root, so the chmod-based write-failure tests can't fail as intended (in_process_redirect ×3, repair ×2, core lib ×4).
  • The e2e_bun_lockb ×2 tests need patches-api.socket.dev and a pinned bun.
  • CI is green on every head of this PR.

The npm, pypi and gem wrappers only dispatch to the binary, so they need no change.

/code-review high findings not fixed

• Corrupt ledger under -g fails open. A corrupt .socket/vendor/state.json
  yields no keys, so the old -g behavior returns. Failing closed would refuse
  every -g run (npm included) started in a project with a corrupt ledger,
  and project-scope commands already report the corruption. Not worth the
  blast radius.
• remove -g reads the ledger once more. One small extra file read on a
  global run, which is otherwise never locked against the vendor flow; it isn't
  a correctness issue.

https://claude.ai/code/session_011f9aeT3Qr5oee9inqu1TVJ

Generated by Claude Code