Fix lockless Gemfile pinning shared-home gems (#1125)

[Mikola Lysenko (mikolalysenko)]

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

Fixes #1125

Summary

In a project with a Gemfile / gems.rb and no Gemfile.lock / gems.locked (a library repo before bundle install), a hosted scan pinned whatever version the machine's shared gem home held:

• gem "x", "~> 2.0" was rewritten to source "<patch registry>" do gem "x", "1.0.0" end, a downgrade below the user's constraint.
• A gem the Gemfile never declared was appended as a new dependency.

Both runs exited 0 with action: pinned. rollback / remove can't undo a Gemfile-only pin, because CLI_CONTRACT "Lockless pins" says it isn't a reference.

Root cause

The #1060 guard (redirect_gem_version_not_locked) in rewrite_gem sits inside if let Some(specs) = &locked. With no lock, locked is None, so a crawled shared-home version fell through to the exact-pin rewrite and the append-a-block branch.

Fix

Hosted mode re-points the version a lock resolves and never picks one itself. So with no lock, every gem is now skipped with the new additive warning redirect_gem_no_lockfile, and nothing is written. The warning detail names the gem and asks for bundle lock (or bundle install), a commit, and a re-run. This follows the maintainer's triage: "Require a resolve/lock step with a clear remedy." CLI_CONTRACT.md documents the code in the additive-codes list and the warnings table.

Several existing rewriter unit tests used lockless Gemfiles to exercise Gemfile spelling logic: paren calls, CRLF, rotated grants, and gems.rb twins. They now carry a minimal CHECKSUMS-less lock through a new gem_lock_resolving helper. That lock shape leaves the lock untouched, so those tests still check exactly what they checked before.

Tests (per issue)

• Hosted gem scan of a Gemfile with no lock still pins shared-gem-home versions: gem "x", "~> 2.0" becomes the older patched "1.0.0", and a gem the project never declared is appended as a new dependency #1125 unit: patch::redirect::tests::gem_without_a_lock_is_never_pinned covers a ~> 2.0 range, an undeclared gem, an exact pin, and the gems.rb spelling. No files, no edits, one redirect_gem_no_lockfile.
• Hosted gem scan of a Gemfile with no lock still pins shared-gem-home versions: gem "x", "~> 2.0" becomes the older patched "1.0.0", and a gem the project never declared is appended as a new dependency #1125 e2e (real binary + mock API): e2e_redirect_gem_stale_install::gem_hosted_scan_without_a_lock_pins_nothing uses a shared-home copy at 1.0.0 with a lockless ~> 2.0 Gemfile and with an undeclared gem. Exit 0, redirected: 0, and the Gemfile is byte-identical.

Red→green: with the guard disabled, the e2e fails at the redirected: 0 assertion, and the unit test failed before the fix.

Commands run

• cargo test -p socket-patch-core --tests: all pass. The lib run is 6110 tests.
• cargo test -p socket-patch-cli --all-features --test hosted_memory_engine --test e2e_vex_redirect --test e2e_vex_lockfile --test e2e_redirect_gem_stale_install --test in_process_vendor: all pass
• cargo test -p socket-patch-cli --test e2e_redirect_gem_build -- --ignored (Bundler 4.0.15): 28 passed
• cargo clippy --workspace --all-features -- -D warnings: clean
• cargo fmt --all -- --check: clean for the changed files. The upstream/mod.rs diff already exists on main.

🤖 Generated with Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 25aabce. Configure here.}