test(yarn): version-matrix e2e capstones — yarn2/3 refusal pins, berry workspaces + pnpm-linker install proofs - #200

Why (empirical basis)

A 36-cell yarn version-matrix e2e sweep (2026-08-18, against real production data) proved three behaviors WORK today that no test pinned:

1. yarn 2 (2.4.3) / yarn 3 (3.8.7) locks are refused cleanly by both lockfile-touching modes. Hosted redirect refuses per-file with warning code redirect_yarn_berry_cache_unsupported (scan exits 0, yarn.lock byte-identical); vendored refuses per-package with errorCode vendor_yarn_berry_cache_unsupported (exit 1, status partial_failure, zero mutations, no .socket/vendor artifacts). Until now the cacheKey gates were only unit-tested against synthetic lock strings — a regression against a REAL yarn 2/3 lock (e.g. a partial rewrite before the refusal fires) would have shipped unseen.
2. yarn 4 workspaces (nodeLinker: node-modules, root + member with the patched dep): hosted redirect and vendored wiring both rewire the MEMBER's dep from a root scan; fresh --immutable --check-cache installs serve the patched bytes.
3. yarn 4 nodeLinker: pnpm (berry's node_modules/.store symlink layout): discovery crawls the layout and hosted + vendored work end-to-end — previously unmentioned anywhere in code or tests.

What each capstone pins (test-only PR, no production code)

e2e_yarn_legacy_cachekey_refusal_build.rs (4 tests)

One cell per yarn-version × compression combo, each doing a REAL corepack yarn@2.4.3 / yarn@3.8.7 install of left-pad@1.3.0, then:

• cacheKey pin: asserts the lock carries the empirically observed cacheKey — 7 / 7c0 (yarn 2, default / compressionLevel 0) and 8 / 8c0 (yarn 3). If a future corepack pin emits a different cacheKey this assertion fails FIRST with a self-describing message, so the refusal contract is never asserted against a lock the test no longer generates.
• hosted refusal: scan --mode hosted → exit 0, status: success, redirect.redirected == 0, zero rewritten files, warning CODE redirect_yarn_berry_cache_unsupported (with the observed cacheKey named in the detail), yarn.lock + package.json byte-identical, no .socket/vendor.
• vendored refusal: scan --mode vendored → exit 1, status: partial_failure, download.downloaded == 1 (the refusal is at the wiring step, not discovery), per-package failed event with errorCode vendor_yarn_berry_cache_unsupported, byte-identity of both files, no .socket/vendor, no spilled blobs.

e2e_yarn4_workspaces_build.rs (2 tests)

Root (ws-root, no deps) + packages/app member depending on left-pad@1.3.0, real corepack yarn@4.12.0:

• hosted: root scan redirects the member's dep (__archiveUrl + real 10c0 checksum via the bootstrap-resolution trick from the redirect sibling), neither package.json touched, workspace lock entries stay workspace-resolved; fresh checkout of committable files only passes yarn install --immutable --check-cache offline-from-registry and the member resolves the PATCHED bytes through yarn node.
• vendored: vendor --offline puts resolutions on the ROOT package.json (member byte-identical), file: locator in the lock; same fresh-checkout + member-resolution proof; --revert restores root package.json AND yarn.lock byte-for-byte and removes .socket/vendor.

e2e_yarn4_pnpm_linker_build.rs (2 tests)

Same shapes with .yarnrc.yml nodeLinker: pnpm, plus layout-specific assertions: node_modules/left-pad is a symlink, .store holds the backing entry (a left-pad-file-<hash> store entry for the vendored leg — proving the vendored tarball, not the registry, fed the store), and yarn node's require.resolve serves the patched bytes through the symlinks.

All three suites follow the existing sibling patterns exactly (e2e_redirect_yarn_berry_build.rs / e2e_vendor_yarn_berry_build.rs): corepack soft-skip with println, per-file wiremock helper, marker blob + hashes computed from installed bytes, cache_env::isolate cache sandbox, seed-then-scrub YARN_* tripwires. No [[test]] declarations needed (auto-discovered), no #[serial] (no tampered-twin cache hazard; every cell installs into its own tempdir with a private global folder).

CI-time note

Warm local timings: refusal suite 2.0s (4 tests), workspaces 1.9s, pnpm-linker 1.9s. Installs are left-pad-only. Cold CI adds one-time corepack downloads of yarn 2.4.3 and 3.8.7 (yarn 4.12.0 is already pulled by the existing berry suites) into the shared cache_env sandbox. All tests soft-skip with a println when corepack or the registry is unavailable.

Local evidence

• cargo test -p socket-patch-cli --test e2e_yarn_legacy_cachekey_refusal_build — 9 passed (4 capstones + 5 cache_env selftests), refusal OK markers printed for all 8 legs (no skips)
• cargo test -p socket-patch-cli --test e2e_yarn4_workspaces_build — 7 passed, HOSTED REWIRE / FRESH INSTALL + MEMBER RESOLUTION / VENDOR / REVERT all OK
• cargo test -p socket-patch-cli --test e2e_yarn4_pnpm_linker_build — 7 passed, same markers incl. YARN NODE RESOLUTION
• cargo clippy --workspace --all-features -- -D warnings — clean

No discrepancies vs the sweep: every behavior the sweep called pass reproduced under the new capstones.

🤖 Generated with Claude Code