GeezerVison

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

Fixes #880
Fixes #881

Root cause

In a pnpm workspace with per-project locks (sharedWorkspaceLockfile: false), a member has its own pnpm-lock.yaml, so both hosted and vendored runs from the member go ahead. Both then looked for pnpm settings only at <cwd>/pnpm-workspace.yaml:

• hosted engine.rs::read_workspace → pnpm_trust planned a Create of a nested packages: ['.'] + trustLockfile: true file (Hosted scan from a pnpm 11/12 workspace member with its own lock writes trustLockfile into a nested member pnpm-workspace.yaml that pnpm ignores, so the root install fails with ERR_PNPM_TARBALL_URL_MISMATCH #880);
• vendored pnpm_lock.rs::read_project → the override was mirrored into a newly created nested packages: ['.'] + overrides: file (Vendored scan from a pnpm 11/12 workspace member with its own lock writes the override into a nested member pnpm-workspace.yaml that pnpm ignores, so the root frozen install fails and a plain pnpm install silently reinstalls the unpatched package #881).

pnpm reads settings only from the nearest pnpm-workspace.yaml above the member, which is the workspace root's, so both writes are ignored. On pnpm 11/12, root installs then fail (ERR_PNPM_TARBALL_URL_MISMATCH / ERR_PNPM_LOCKFILE_CONFIG_MISMATCH), or for vendored mode, a plain install silently drops the patch.

Fix

• Shared lookup utils::pnpm_workspace::governing_workspace_file: for a project with no pnpm-workspace.yaml of its own, it returns the nearest ancestor pnpm-workspace.yaml. Both modes use it.
• Hosted (governing_root::refusal, which runs before any takeover or write, dry runs included): a member with its own v9 lock whose root file neither trusts the lock nor explicitly opts out is refused with redirect_pnpm_settings_elsewhere. The message names the root file and tells the user to add trustLockfile: true there, or to pass --no-trust-lockfile-config. Once the root file trusts the lock or opts out, the member is pinned, no nested file is created, and the redirect_pnpm_trust_lockfile warning names the root file (pnpm_trust).
• Vendored (read_project, shared by the vendor step and the pre-download preflight): refused with vendor_pnpm_settings_elsewhere, naming the governing file and pointing at --mode hosted.
• Both codes are documented in CLI_CONTRACT.md.

Why refuse instead of writing the root file: hosted and vendored writes, and their ledgers and reverts, are all scoped to the project directory, and the vendored file: override path would have to be re-rooted for the root file. Refusing before any write follows the existing #590 / #598 governing-root pattern. Behaviour change: pnpm 9/10 users of this layout previously got a run that "worked" but left a nested packages: ['.'] file. That file turns the member into its own workspace whenever pnpm runs inside it. These users now get the refusal. Hosted mode's remedy is one line in the root file that pnpm ≤ 10 ignores. Vendored mode's remedy is to use hosted mode.

Ported #878 (commit 5d94800): main's production_digests_go_through_the_helpers guard is red, and this carries #878's 3-file Gradle digest fix so CI can go green. It becomes a no-op once #878 lands.

Tests (red → green)

pnpm_member_with_own_lock_or_lockless_root_is_left_alone now gives its root file trustLockfile: true, so it keeps testing what its name says (no lock-elsewhere refusal).

Local runs

• cargo clippy --workspace --all-features -- -D warnings: clean.
• cargo test -p socket-patch-cli --all-features --test in_process_redirect_pnpm: 18/18 pass.
• e2e_redirect_pnpm_build -- --ignored --skip pnpm_pinned_matrix (real pnpm): 8/8 pass. e2e_vendor_pnpm_build: 24/24 pass, plus the ignored pinned matrix with SOCKET_PATCH_PNPM_E2E_VERSION=10.28.0: 1/1 pass.
• cargo test --workspace --all-features --no-fail-fast: everything passes except 12 tests that inject write failures with chmod 0o555 / read-only parents. The sandbox runs as root, so those writes succeed: covgap_commands_vendor ×3, in_process_redirect ×3, repair ×2, and core copy_tree / vlt_heal / pypi_poetry / pypi_requirements. None touch pnpm settings, and CI runs them as non-root. The 13th, the digest guard, is fixed by the Route Gradle digests through utils::digest #878 port.
• cargo fmt: main itself isn't rustfmt-clean with the pinned 1.93.1 toolchain (466 diffs), so only this PR's own hunks are formatted.

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

🤖 Generated with Claude Code

https://claude.ai/code/session_018d82ZH8U4XqGShmX3UgoEx

Generated by Claude Code