[Mikola Lysenko (mikolalysenko)]

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

Fixes #1808

Summary

Vendored gem mode failed with apply_failed ("Gemfile.lock has no GEM section") on any Gemfile.lock with CRLF line endings. Git for Windows core.autocrlf and eol=crlf produce such locks, and Bundler keeps CRLF on purpose. Because the hosted→vendored eject dry run never reaches that edit, vendor --dry-run and scan --mode vendored --dry-run previewed eject_planned (exit 0) while the real run failed and rolled back (exit 1).

After this PR a CRLF lock vendors, re-runs (in-sync hot path) and --reverts like an LF one. It's edited in LF form and written back in CRLF, so the result stays byte-exact. Dry and wet runs agree again.

Root cause

vendor/gem.rs does its lock surgery (edit_lock, its section and entry helpers, and the revert splices) by splitting on \n and comparing lines exactly. On a CRLF lock every line keeps a trailing \r, so GEM and specs: never match. Hosted mode already handles CRLF through utils::line_endings. The vendored path didn't.

Fix

• lock_lf_form (new, shared): a CRLF lock is folded to LF and its LineEndings is remembered. gem_prelude reads the lock through it, so every forward check sees LF text: the already-wired hot path, lock_checksum_in_sync and edit_lock. The edit is written back with LineEndings::restore.
• RevertFiles reads the lock through the same helper and writes it back in its own ending. Ledger records stay bare LF lines, the same as for an LF lock, so revert is byte-exact.
• A lock that mixes CRLF and LF has no single ending to restore. It fails closed before any other check with "mixes CRLF and LF line endings" (the same apply_failed class as the other edit_lock shape failures) and writes nothing. The hosted restore already refuses such a lock the same way.
• docs/ecosystems.md: one line on CRLF locks in the gem vendored cell.

Tests (red → green)

Each new test fails on main with the issue's exact error and passes with the fix.

Test	Covers	Without fix	With fix
vendor::gem::tests::crlf_lock_vendors_in_crlf_and_reverts_byte_exact (unit)	direct and transitive CRLF lock: dry, wet, hot-path re-run, byte-exact revert	FAIL "has no GEM section"	pass
vendor::gem::tests::crlf_checksums_lock_vendors_and_reverts_byte_exact (unit)	bundler ≥ 2.6 CHECKSUMS lock in CRLF	FAIL	pass
vendor::gem::tests::mixed_line_ending_lock_fails_closed (unit)	mixed lock fails closed dry and wet, writes nothing	FAIL (wrong error)	pass
e2e_vendor_gem_build::gem_vendor_crlf_lock_fresh_checkout_and_revert (real bundler)	issue symptom 1: plain vendor dry and wet, frozen fresh-checkout install keeps the CRLF lock byte-identical, idempotent re-run, byte-exact revert	FAIL "has no GEM section"	pass
e2e_redirect_gem_build::gem_hosted_pin_with_a_crlf_lock_ejects_cleanly (real bundler)	issue symptom 2: vendor eject (CRLF lock only; CRLF pair) and scan --mode vendored takeover, dry and wet both exit 0, lock stays CRLF	FAIL at wet (exit 1, apply_failed + rollback)	pass

Per-issue checklist:

• Vendored gem mode fails apply_failed ("Gemfile.lock has no GEM section") on any CRLF Gemfile.lock, and the hosted→vendored vendor --dry-run eject still previews eject_planned #1808 symptom 1 (plain vendored, CRLF lock): unit tests above + gem_vendor_crlf_lock_fresh_checkout_and_revert
• Vendored gem mode fails apply_failed ("Gemfile.lock has no GEM section") on any CRLF Gemfile.lock, and the hosted→vendored vendor --dry-run eject still previews eject_planned #1808 symptom 2 (eject/takeover dry/wet parity on a CRLF lock): gem_hosted_pin_with_a_crlf_lock_ejects_cleanly

Commands run locally (Linux, ruby 3.3.6, bundler 4.0.18):

• cargo fmt --all -- --check: ok
• cargo clippy --workspace --all-features -- -D warnings: ok
• cargo test -p socket-patch-cli --all-features --test e2e_vendor_gem_build --test e2e_redirect_gem_build -- --ignored: all pass on bundler 4.0.18 and 4.0.21 (4.0.21 refuses a frozen install of any CRLF lock, including a pristine one socket-patch never touched, so on that bundler the CRLF test checks a plain install keeps the vendored lock byte-identical instead)
• cargo test --workspace --all-features --no-fail-fast: all pass except 11 tests that also can't pass in this sandbox and don't touch gem code. 9 are write-failure tests that rely on read-only modes the container's root user ignores (in_process_redirect ×3, repair ×2, core lib copy_tree/vlt_heal/pypi_poetry/pypi_requirements). 2 are e2e_bun_lockb tests that need the live patches-api.socket.dev, which the sandbox proxy blocks. CI is the authoritative run.
• Wrappers (npm/, pypi/, gem/) only dispatch to the binary, so they need no change.

/code-review high: findings not changed here

• A CRLF Gemfile gets its spliced line in LF. Since fixed on main by Fix vendored Gemfile line endings on CRLF (#1821) #1822, which this branch now merges. The CRLF eject e2e also asserts the Gemfile keeps CRLF.
• A mixed lock reports apply_failed instead of a new dedicated code. That matches every other edit_lock shape failure. A new code needs CLI_CONTRACT table changes.
• The already-wired hot path reads a mixed lock raw. That's exactly what main does, so there's no behavior change for mixed locks beyond the fail-closed edit.
• Fixed from the review: the mixed check now runs first, a no-op normalization in the takeover preflight is gone, the forward and revert paths share one helper, and the e2e doc is accurate.

Follow-up (not in this PR)

The eject/takeover dry-run preview (takeover_dry_refusal) still ignores a failed Done from the backend. Only Refused outcomes are previewed. With CRLF fixed, no gem lock shape I could build reaches it: the hosted restore refuses mixed locks first. A generic preview of backend failures would touch every ecosystem, so it's left for a separate change.

---

Note

Medium Risk
Changes Gemfile.lock read/write and revert logic for all vendored gem flows; behavior is well-tested but incorrect EOL handling could corrupt locks or break Bundler installs.

Overview
Fixes #1808: vendored RubyGems mode used to fail on CRLF Gemfile.lock files (common on Git for Windows autocrlf checkouts) with apply_failed / "Gemfile.lock has no GEM section", because lock surgery split on \n and matched section headers that still had trailing \r. Hosted mode already normalized line endings; vendored mode did not, which also made dry-run eject/takeover preview exit 0 while wet runs failed and rolled back.

The vendored gem path now folds CRLF locks to LF for editing, remembers the original style via lock_lf_form, and writes back with LineEndings::restore on vendor and revert. Mixed CRLF/LF locks fail closed before any write. Docs note CRLF support in the gem vendored matrix cell.

Coverage adds unit tests (CRLF vendor/revert, CHECKSUMS locks, mixed failure) and ignored e2e tests with real Bundler for plain vendor, hosted→vendored eject, and scan --mode vendored on CRLF locks (including Gemfile CRLF per #1821).

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

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

Labeled Ready for review by the burn-down agent.

• Head: e38787013a4dcfaac43cf290634ae53a21db5221
• CI: 50/50 check runs passing on this head (31 success, 19 skipped); no main-wide failures.
• Bugbot: reviewed e387870, no new issues; no unresolved review threads.
• Mergeable, no conflicts; CHANGELOG.md untouched.
• Reviewer focus: CRLF handling in crates/socket-patch-core/src/vendor/gem.rs (mixed-ending locks are refused up front) and the frozen-leg comparison in the CRLF e2e.

Slack announcement not sent this run (Slack posting unavailable); the next run should retry.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Final review brief

What it does. Vendored gem mode failed with "Gemfile.lock has no GEM section" on a CRLF Gemfile.lock (Git for Windows autocrlf), and the eject dry run previewed success while the real run failed (#1808). Now the lock is read in LF form, edited, and written back in CRLF. Revert does the same, so the lock comes back byte-identical. A lock that mixes CRLF and LF fails closed before any write.

Risk: low. An LF lock passes through lock_lf_form unchanged, so nothing changes for existing users. The ledger keeps bare LF lines, as before.

Look here

• gem.rs:1776: lock_lf_form, the shared helper
• gem.rs:394 and gem.rs:756: forward read and CRLF write-back
• gem.rs:492: mixed-ending refusal
• gem.rs:2291 and gem.rs:2323: revert read and write-back

Verified. Read the full diff. Checked that LineEndings::restore is the identity for LF/None/Mixed, and that the takeover preflight's lock readers (lock_lists_direct_dependency, bundler_merges_dev_dependencies) already accept CRLF, so dry and wet runs agree. The unit tests cover CRLF direct/transitive/CHECKSUMS locks, hot-path re-runs and a byte-exact revert, and real-bundler e2e covers both issue symptoms. CI 50/50 on e387870 (31 success, 19 skipped), Cursor Bugbot green, mergeable, no open review threads, CHANGELOG.md untouched.

Changes I made. None.

Open questions. None blocking. The PR notes follow-ups: a CRLF Gemfile gets its spliced line in LF (pre-existing, #815), and the takeover dry run doesn't preview backend Done failures.

Auto-merge is armed, so approving sends this straight to the merge queue.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[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 8486320. Configure here.}

[Mikola Lysenko (mikolalysenko)]

[agent] Re-enqueued once (final reviewer) after the 13:40 merge-queue eviction: main has since been merged into the branch, head 8486320 is approved, ci-ok/clippy green, mergeable, no open threads. Approvals stay valid across later pushes per the repo owner's rule.

---

Generated by Claude Code