GeezerVison

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

Fixes #482
Fixes #548

Root cause

Both Gemfile rewriters decide between "rewrite the declaration" and "append a block" from a regex probe of the root Gemfile text alone:

• Hosted (patch/redirect/mod.rs, rewrite_gem): gem_line_re.captures(gf) takes only the first literal match. A gem declared twice (for example in two group blocks, Hosted gem redirect rewrites only the first of a gem's declarations, so a gem listed in two group blocks makes every bundle install fail with "You cannot specify the same gem twice" #548) gets one line rewritten to = x.y.z while the other stays >= 0, so Bundler refuses the Gemfile.
• Hosted + vendored (declared_re / plan_gemfile_edit): when the root text shows no declaration, the gem is treated as transitive and a block is appended. The rewriter never checks whether Bundler sees the gem as a direct dependency through eval_gemfile or a loop (Hosted gem redirect appends a second declaration when the gem is declared through eval_gemfile or a loop, so every bundle install fails with "You cannot specify the same gem twice" #482). It ends up declared twice, and every bundle install exits 4.

Fix

• formats/gem: the shared lock parser now records every DEPENDENCIES entry (GemfileLock::direct), exposed as lock_lists_direct_dependency.
• Hosted: a declaration count runs first, over gem calls whose first argument is the gem (another gem's require: "x" or a comment quoting the name does not count). More than one declaration gives redirect_gem_declared_more_than_once, with nothing written and nothing attested (vendored mode already refused this shape). Before appending, a gem the lock lists as direct gives redirect_gem_declaration_not_visible instead.
• Vendored: an Append plan for a gem the lock lists as direct is refused as gemfile_declaration_not_editable (refuse_append_of_direct_dependency).

Trade-off: a gemspec development dependency also appears under DEPENDENCIES, so patching one of those through an appended block is now refused rather than relying on Bundler's "gemspec dependency overridden" warning path. This fails closed, and the warning text names the gemspec case.

Test evidence

Red→green: with the fix neutered (lock_lists_direct_dependency forced to false, duplicate-declaration guard disabled), all three new unit tests fail; with the fix they pass.

Commands run locally (Ruby 3.3.6, Bundler 4.0.17):

• cargo clippy --workspace --all-features -- -D warnings: clean
• rustfmt --check on every file this PR touches: hunks clean (main has pre-existing unformatted code elsewhere, and CI does not gate on fmt)
• cargo test --workspace --all-features --no-fail-fast: 208 test binaries ok. 12 failures, all write-permission-failure tests (*_write_failure_*, *unremovable*, relax_loop_must_not_traverse_symlinked_root) that cannot fail as root in this sandbox. None touch gem code.
• cargo test -p socket-patch-cli --all-features --test e2e_redirect_gem_build -- --ignored: 10 passed
• cargo test -p socket-patch-cli --all-features --test e2e_vendor_gem_build -- --ignored: 6 passed (re-run on e13a087: both gem build suites green again)
• e2e_gem needs the live patch API, which this sandbox cannot reach; left to CI

🤖 Generated with Claude Code

https://claude.ai/code/session_01Lkn7GeDBpBAZrZ1sFQuc1y

Generated by Claude Code