Fix pnpm member settings written to an ignored nested pnpm-workspace.yaml (#880, #881)

[Mikola Lysenko (mikolalysenko)]

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)

Issue	Test	Without fix	With fix
#880	in_process_redirect_pnpm::hosted_scan_from_pnpm_member_with_own_lock_never_nests_trust_config	FAIL: exit 0 (left Some(0), right Some(1))	ok
#880	in_process_redirect_pnpm::hosted_scan_from_pnpm_member_respects_root_trust_opt_out	FAIL: nested pnpm-workspace.yaml created	ok
#880	governing_root::tests::pnpm_member_with_own_lock_needs_the_root_to_trust_it (unit)	n/a (new code path)	ok
#881	vendor::pnpm_lock::tests::workspace_member_with_its_own_lock_is_refused_before_any_write (wet, dry run, preflight)	FAIL: vendoring proceeded	ok
shared	utils::pnpm_workspace::tests::*	n/a	ok

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

---

Note

Medium Risk
Changes hosted/vendored preflight and refusal paths for pnpm workspace members with own locks; behavior shifts from silent nested files to fail-closed errors until root trustLockfile is set.

Overview
Fixes pnpm workspace members that use per-package locks (sharedWorkspaceLockfile: false): hosted and vendored runs no longer create a nested pnpm-workspace.yaml in the member (pnpm ignores it and only reads settings from the ancestor root file).

Hosted adds a pre-write refusal (redirect_pnpm_settings_elsewhere) when the member has a v9 lock but the root pnpm-workspace.yaml does not yet set trustLockfile (unless the user passes --no-trust-lockfile-config). After the root trusts the lock—or explicitly opts out—pins proceed and trust warnings reference the root file, not a nested scaffold.

Vendored refuses the same layout with vendor_pnpm_settings_elsewhere because overrides: cannot be applied in the member; remedy is --mode hosted.

Shared helper governing_workspace_file resolves which workspace YAML governs a project; CLI_CONTRACT.md documents both codes.

Also routes Gradle/JVM SHA1/SHA256 hashing through shared utils::digest helpers (CI guard / #878 port).

^{Reviewed by Cursor Bugbot for commit 83c5105. Configure here.}

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

[agent] The coverage and test (windows-latest) failures ran on cc52870, the empty start commit. That commit is byte-identical to main (9c43dfc), where utils::digest::tests::production_digests_go_through_the_helpers is red because the Gradle files hash digests inline. The current head, 5d94800, ports #878's 3-file fix for that guard, and it passes locally. I'm watching CI on 5d94800.

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[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 83c5105. Configure here.}

[Mikola Lysenko (mikolalysenko)]

[agent] lock-diff (vlt patch compatibility, run 37373110741) failed on 83c5105 without comparing any locks. Its plan and build (ubuntu-latest) jobs were cancelled after 15 minutes queued with no runner assigned. As a result native was skipped, no vlt-results-* artifacts were produced, and every required cell reported "locks from no OS". No test body ran, and this PR doesn't touch vlt. I've re-run the failed jobs once.

test (windows-latest) and coverage in CI run 37373110800 were cancelled the same way, with no runner ever assigned. They'll be re-run once that run finishes (macOS jobs are still queued).

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Burn-down agent: labeled Ready for review at 83c5105 (83c510589d28649dda1cf0893c75dfb9dd993721).

• CI: 533/533 workflow checks green on the head commit (6 skipped by matrix rule), after re-running jobs the GitHub Actions runner outage cancelled. No test failed. The only non-green entry is 1 CodeQL default-setup Analyze (javascript-typescript) job that GitHub cancelled during the outage, and GitHub doesn't allow re-running it.
• Bugbot: reviewed 83c5105 with no new issues, and no review threads are open.
• Mergeable against main, with no conflicts. Approved by Tanmay Singla (@Tanmay182003) on this SHA.

---

Generated by Claude Code