GeezerVison

Summary

Fixes the e2e (ubuntu-latest, e2e_safety_pnpm) CI failure (apply_in_a_does_not_mutate_b_or_store) that has been red on main since 70b41d6 — a dep-bump-only commit, which is the tell that the cause was environment drift, not code.

Root cause: pnpm ≥ 10.34 (the runner's floating pnpm@10 resolved to 10.34.5 on 2026-07-10, between the last green and first red run) records every project the store serves as a symlink under <store>/v10/projects/<hash> → ../../proj_x. The test's walk_dir followed those links back into the project trees, so find_store_file_with_content could return proj_a's own node_modules copy of index.js — freshly patched — and misreport it as "the store entry", tripping the store-must-stay-unpatched asserts. Whether it did depended on readdir order: deterministic-red on ubuntu's ext4, green on macOS/Windows, flip-flopping run-to-run in a Linux container.

The CoW defense was never broken. Inode forensics on failing fixtures show the real CAFS entry untouched: proj_b and the store still share the original inode (nlink 2) with original bytes, proj_a on a fresh private inode — exactly the invariant the test exists to prove. The sibling test (pnpm_install_in_b_does_not_revert_a) additionally masked the walker bug because pnpm's frozen install self-heals content-addressed entries.

Fix: the store walker skips symlinks (symlink_metadata, treat-unreadable-as-skip). Lossless — the store's real content (files/, index/) contains no symlinks — and inert on older pnpm layouts that have no projects/ dir.

Testing

Linux container with pnpm 10.34.5 (the failing environment; reproduced red on first try before the fix): full e2e_safety_pnpm suite run 5×, 4/4 tests green every run.

🤖 Generated with Claude Code