GeezerVison

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

Refs #823 (slice 23)

Problem

Test children that run bundle each had their own environment scrub,
and the copies had drifted:

• e2e_vendored_production, e2e_vendor_gem_build and
  e2e_redirect_gem_build swept every BUNDLE_* and every
  GEM_* by hand. Removing GEM_HOME/GEM_PATH goes against
  tests/common/cache_env.rs's rule: rvm/chruby export them and
  bundle resolves through them, so the suites could break a
  developer's version-managed ruby. Two of the three also skipped the
  SOCKET_* scrub.
• e2e_hosted_production ran bundle through tool() with no bundler
  scrub, so an ambient BUNDLE_PATH, BUNDLE_FROZEN or RUBYOPT reached it.
• The production suites' socket-patch child got only Extra::Venv, so
  an ambient BUNDLE_PATH/BUNDLE_GEMFILE or COMPOSER_VENDOR_DIR moved
  the crawl off the fixture.

Change (test-only)

• hermetic::Extra::Bundle also removes RUBYOPT (a bundle exec
  shell sets -rbundler/setup, which pins child rubies to the outer
  Gemfile). It keeps GEM_HOME/GEM_PATH, as before.
• New hermetic::CRAWLER_EXTRAS (Venv, Bundle, Composer) for a
  socket-patch child that crawls a real tree. The production suites'
  run/run_socket and vex_e2e_common::run_vex use it. Env a test
  passes is applied after the scrub, so it still wins.
• The three bundle helpers use scrub_socket_vars +
  Extra::Bundle. Both production suites' pm_command adds
  Extra::Bundle, which covers the hosted tool("bundle") calls.
• spawn_env_hygiene: the bundle test also checks RUBYOPT is removed
  and GEM_PATH kept; a new test covers CRAWLER_EXTRAS; a new ratchet
  no_private_bundler_sweeps rejects a hand-rolled
  starts_with("BUNDLE_") sweep outside hermetic.rs.
• Review follow-up: socket-patch children that crawl a real tree go
  through hermetic::scrub_crawler_inputs (CRAWLER_EXTRAS plus
  BUNDLE_USER_CONFIG pinned to a missing file, so the ruby crawler
  can't fall back to a developer's ~/.bundle/config). The pin is not
  in Extra::Bundle, because bundle children get their own
  BUNDLE_USER_HOME from cache_env::isolate, which it would shadow.
  Extra::Bundle also drops RUBYLIB (set by bundle exec). The gem
  build suites' run_socket use the same helper.

Evidence

• cargo test -p socket-patch-cli --all-features --test spawn_env_hygiene:
  20 passed. On origin/main the new ratchet would flag the 3 helper
  files (grep 'starts_with("BUNDLE_")' matches them there).
• cargo test -p socket-patch-cli --all-features --test spawn_env_hygiene --test e2e_vendor_gem_build --test e2e_redirect_gem_build --test e2e_redirect_gem_stale_install --test apply -- --include-ignored
  (ruby 3.3.6): 20 + 43 + 51 + 42 + 136 passed.
• cargo fmt --all -- --check and cargo clippy --workspace --all-features -- -D warnings (the CI lint) are clean. The production
  suites compile (--no-run). They and e2e_gem need the live
  patches API, which this sandbox can't reach ("tunnel error"), so they
  run on the scheduled full tier.
• A full cargo test --workspace ran out of disk in the sandbox. The
  lean PR run covers it.

Code review (/code-review high)

Fixed: missing #[serial] on the new hygiene test; the
~/.bundle/config fallback for crawler spawns; RUBYLIB under
bundle exec; thin assertions in the new test; the stale
GEM_SPEC_CACHE doc; the gem build suites now use the shared helper.

Not fixed, with reasons:

• Apply the crawler scrub inside hermetic::command for every spawn.
  That changes ~20 more suites, so it belongs in a later Spawn every CLI test child through one hermetic Command builder; 10 test files inherit ambient SOCKET_* today #823 slice
  rather than this one.
• Widen no_private_bundler_sweeps to other spellings. It is a ratchet
  against copying the old pattern back. A fuzzier match would flag
  legitimate code, and the env tests are what actually pin behavior.
• Share pm_command between the two production suites. That duplicate
  predates this PR and is out of scope here.
• Use tool_command("bundle") for Windows bundle.bat. The gem build
  suites only run on Linux.

CI cost

Test-only, no workflow changes. A lean PR run keeps the same job count
and minutes (about 28 Linux jobs, ~8 min wall), before and after.

🤖 Generated with Claude Code

https://claude.ai/code/session_018oK2ooQLZpyw2hVVqctE9C

Generated by Claude Code

Generated by Claude Code