GeezerVison

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

Fixes #483
Fixes #507

Summary

Gem modes now read Bundler settings in Bundler's own priority, with the local app config over the environment.

• Gem manifest resolution lets the BUNDLE_GEMFILE env var override .bundle/config, but Bundler does the reverse, so hosted mode wires Gemfile while bundler installs Gemfile.next unpatched and VEX attests it #507: When BUNDLE_GEMFILE is set in both .bundle/config and the environment, the .bundle/config value now wins, as it does in Bundler. Before, a dual-boot project (bundle config set --local gemfile Gemfile.next) with an exported BUNDLE_GEMFILE=Gemfile had its Gemfile rewired and attested, while Bundler installed Gemfile.next unpatched. That project now gets redirect_gem_bundle_gemfile_unsupported, nothing is redirected, and nothing is attested. Vendored mode uses the same resolver (vendor/gem.rs → bundler_loaded_manifest), so it is fixed too.
• Gem hosted stale-install guard only checks vendor/cache, so a committed cache at a configured cache_path gets no warning, the in-run VEX attests it, and Bundler 2.4 installs the unpatched gem #483: The hosted gem stale-install guard now looks for the committed archive in Bundler's configured cache dir (BUNDLE_CACHE_PATH in the app config, then the env var, else vendor/cache) instead of always vendor/cache. Both flavors use it: the standalone warning and the folded delete-list remedy. A stale archive there now warns and keeps the same run's VEX from attesting the purl.
• Both settings skip .bundle/config when BUNDLE_IGNORE_CONFIG is set, as Bundler does.

Root cause

socket-patch read Bundler settings one key at a time, with no resolver that follows Bundler::Settings priority (local app config $BUNDLE_APP_CONFIG/config / .bundle/config first, then ENV):

• gemfile: formats/gem/manifest.rs::classify checked the environment before the app config, which is the reverse of Bundler's order. A unit test even pinned the inverted order.
• cache_path: never read. scan/hosted.rs hard-coded <cwd>/vendor/cache in both guard flavors.

Changes

• crawlers/ruby_crawler.rs: added bundle_config_setting(contents, key), one exact-key app-config reader that config_gemfile now uses. Added bundler_app_cache_dir[_with_env], which resolves cache_path in Bundler's priority (relative to the project root, absolute stands alone, read-only use so no containment needed). Both resolvers load the file through read_app_config, which returns nothing under BUNDLE_IGNORE_CONFIG (Bundler's load_config returns {} for any set value).
• formats/gem/manifest.rs::classify: the app config value now outranks the env. The one exception: an env BUNDLE_GEMFILE naming a file in another directory still decides alone. That value moves Bundler.root, so Bundler reads that root's config and never the project's. The run still refuses, now naming the env var. The inverted unit test is replaced.
• scan/hosted.rs: both stale-guard flavors use the resolved cache dir, and the warning text now says "its cache dir".
• Docs: CLI_CONTRACT.md (the "Gem stale-install guard" section, the redirect_gem_bundle_gemfile_unsupported and redirect_gem_stale_install rows), docs/ecosystems.md, and CHANGELOG [Unreleased] / Fixed.
• No wrapper changes are needed (npm/, pypi/, gem/ only dispatch to the binary).

Per-issue checklist

• Gem manifest resolution lets the BUNDLE_GEMFILE env var override .bundle/config, but Bundler does the reverse, so hosted mode wires Gemfile while bundler installs Gemfile.next unpatched and VEX attests it #507, each test red on main and green here:
  • formats::gem::manifest::tests::config_wins_over_env_like_bundler_settings: config Gemfile.next + env Gemfile gives Unsupported{AppConfig} and the remedy names bundle config unset --local gemfile. Both directions of the supported-spelling conflict are covered too.
  • formats::gem::manifest::tests::env_gemfile_in_another_directory_is_never_overridden_by_project_config
  • crawlers::ruby_crawler::tests::loaded_manifest_app_config_beats_the_environment (on disk)
  • e2e with real Bundler: e2e_redirect_gem_build::gem_hosted_bundle_gemfile_config_outranks_env_redirects_nothing (ScanVexDualBoot + BUNDLE_GEMFILE=Gemfile exported to socket-patch). On main it fails with exactly the reported envelope: "redirected":1,"rewrittenFiles":["Gemfile"],"vex":{"statements":1}.
• Gem hosted stale-install guard only checks vendor/cache, so a committed cache at a configured cache_path gets no warning, the in-run VEX attests it, and Bundler 2.4 installs the unpatched gem #483, each test red on main and green here:
  • commands::scan::hosted::tests::gem_stale_probe_follows_the_configured_bundle_cache_path: covers the standalone warning, the stale_purls VEX exclusion, the folded delete list, and that a leftover vendor/cache archive is ignored once cache_path moves it.
  • e2e: e2e_redirect_gem_stale_install::gem_hosted_stale_archive_at_configured_cache_path_warns_and_is_not_attested, for the app-config, BUNDLE_CACHE_PATH-env and BUNDLE_IGNORE_CONFIG arms. On main the first two fail with the reported symptom: no redirect_gem_stale_install, vex.statements: 1. The ignore-config arm fails the same way on 477aae9.
  • crawlers::ruby_crawler::tests::app_cache_dir_follows_bundler_settings_priority and bundle_config_setting_matches_the_exact_key (new helpers)

Test evidence (Linux, Ruby 3.3.6, Bundler 4.0.17)

• cargo clippy --workspace --all-features -- -D warnings: clean.
• cargo test -p socket-patch-core --all-features --lib: 4720 passed, 4 failed. The 4 failures (copy_tree::relax_loop_must_not_traverse_symlinked_root, vlt_heal::an_unremovable_hidden_lock_keeps_every_store_entry, pypi_poetry::wire_write_failure_…, pypi_requirements::wire_failure_rolls_back_…) fail identically on origin/main. They are permission tests that root bypasses in this sandbox, and they are unrelated to this change.
• cargo test -p socket-patch-cli --all-features --lib: 830 passed.
• --test e2e_redirect_gem_stale_install (25), in_process_gem_apply (11), in_process_gem_multi_platform (7), covgap_commands_scan_hosted (50), hosted_memory_parity (31), core crawler_ruby_e2e (25): all pass.
• --test e2e_redirect_gem_build --include-ignored (19/19) and --test e2e_vendor_gem_build --include-ignored (15/15), with real Bundler: all pass on a757732.
• cargo fmt --all -- --check: main itself is not rustfmt-clean (460 diffs with the pinned 1.93.1 rustfmt, and CI doesn't gate it), so I formatted only this PR's own hunks.
• I did not run a full local cargo test --workspace --all-features: building every integration-test binary used up the sandbox's disk allowance. CI covers it.
• CI on 477aae9: all green, 477 passed, 6 skipped, 0 failed. Bugbot: "no issues found", twice. CI on a757732 is pending.

Follow-ups

• Bundler's global ~/.bundle/config (priority below ENV) is still not consulted for any key. That was already true and is unchanged here.
• The BUNDLE_PATH app-config probe (RubyCrawler::app_config_bundle_path) doesn't honor BUNDLE_IGNORE_CONFIG yet. It only adds a discovery path, it predates this PR, and this PR doesn't touch it.

🤖 Generated with Claude Code

https://claude.ai/code/session_01MWt5CXPnmqVEUZe4wnCfgX