GeezerVison

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

Fixes #498

Summary

vendor under --global / --global-prefix (or SOCKET_GLOBAL / SOCKET_GLOBAL_PREFIX) is now a usage error: exit 2, human Error: --global cannot be used with vendor[ --revert| --check]: global installs have no project lockfile to …, JSON {status: "error", error: {code: "global_scope_unsupported", message}}. This matches scan / get --mode vendored -g. The check runs before the project is read or locked.

Root cause

#446 made get, scan, apply, rollback and remove leave the cwd project's hosted pins and vendor ledger alone under global scope, using commands::project_state_in_scope / global_mode_conflict. The standalone vendor command (commands/vendor.rs) never consulted either one. Only its manifest-less eject path checked is_global(). As a result:

• vendor --revert -g reverted the project's vendoring and exited 0, so the next frozen install was silently unpatched.
• vendor -g vendored the manifest's records into the project and rewired its lockfile, including a hosted→vendored takeover.

The bug isn't specific to vlt. The reporter's npm control reproduces it too, because the code is package-manager independent.

Design choice

The issue allowed either "refuse" or "no-op on the project". I chose refuse, for three reasons:

• Vendored state never exists for global installs, so there is nothing a global vendor could legitimately act on.
• A silent no-op exit 0 would hide that the user's intent was misrouted.
• It is consistent with the existing --mode vendored -g usage error.

vendor --check -g is refused for the same reason: it would report on the project, which isn't the global run's target. The now-unreachable is_global() guard on the eject path was removed.

Changes

• commands/vendor.rs: global_scope_conflict plus an early exit-2 refusal in run.
• commands/mod.rs: the shared global_scope_flag helper, so both usage errors name the flag identically.
• CLI_CONTRACT.md ("Global scope never touches the project's state") and CHANGELOG.md.

Test evidence

New tests in crates/socket-patch-cli/tests/global_scope_project_state.rs (section 5) cover --global, -g, --global-prefix, SOCKET_GLOBAL=1 and SOCKET_GLOBAL_PREFIX, each in human and --json mode:

• global_vendor_revert_leaves_vendored_project_state: the lock, artifact, ledger and installed copy stay byte-identical. A control shows a project-scope revert still unwinds.
• global_vendor_does_not_vendor_into_the_project: the lock and manifest are unchanged and no .socket/vendor is created. A control shows project-scope vendoring still works.
• global_vendor_check_is_refused

Red → green:

• Before the fix (4749634): all 3 failed with left: 0, right: 2. The command exited 0 and touched the project.
• After the fix (0e617ff): cargo test -p socket-patch-cli --all-features --test global_scope_project_state passed 29/29.

Local checks:

• cargo clippy --workspace --all-features -- -D warnings: clean.
• cargo test --workspace --all-features --no-fail-fast: all green. Twelve tests across four targets (covgap_commands_vendor, in_process_redirect, repair, core --lib) fail only because this sandbox runs as uid 0, where their chmod 0o555 write-failure injection can't block writes. Re-run as an unprivileged user, all four targets pass in full (core lib 4719/4719, repair 116/116, in_process_redirect 104/104, covgap_commands_vendor 3/3 of the affected tests). None of them touch this change.
• cargo fmt --all -- --check is already red on main across ~127 unrelated files (CI doesn't run it). The hunks in this PR are rustfmt-formatted, and I left the rest of the tree alone so the diff stays reviewable.
• No wrapper changes are needed: npm/, pypi/ and gem/ only dispatch to the binary.

Per-issue checklist

• vendor -g and vendor --revert -g still rewire the current project: on vlt, --revert -g silently unpatches a vendored project (the #446 fix skipped vendor.rs) #498 vendor --revert -g keeps the project's vendoring → global_vendor_revert_leaves_vendored_project_state
• vendor -g and vendor --revert -g still rewire the current project: on vlt, --revert -g silently unpatches a vendored project (the #446 fix skipped vendor.rs) #498 vendor -g doesn't vendor into the project → global_vendor_does_not_vendor_into_the_project
• vendor -g and vendor --revert -g still rewire the current project: on vlt, --revert -g silently unpatches a vendored project (the #446 fix skipped vendor.rs) #498 SOCKET_GLOBAL / SOCKET_GLOBAL_PREFIX behave like the flags → covered by every test above

Follow-ups

• None for vendor -g and vendor --revert -g still rewire the current project: on vlt, --revert -g silently unpatches a vendored project (the #446 fix skipped vendor.rs) #498. Related but separate: Since #446, scan -g --mode agent then rollback -g from a vendored NuGet project reverts the project's patched package in the shared global packages folder; the locked restore stays "up-to-date" and VEX keeps attesting #489 (a NuGet global packages folder shared with the project after Fix -g touching the cwd project's state (#436, #445) #446) has a different root cause.

Generated by Claude Code