Keep the Ruby 3.2 CI floor off the OpenAI SDK's 3.3 requirement

[simonx1]

Problem

bundle install fails on the Ruby 3.2 matrix job:

openai-0.77.0 requires ruby version >= 3.3.0, which is incompatible with the current version, 3.2.11

#207 moved the git-sourced openai dev dependency to a revision where upstream raised required_ruby_version from >= 3.2.0 to >= 3.3.0. The gemspec here still declares >= 3.2.0 and CI still tests that floor, so resolution on 3.2 has no valid candidate.

It went unnoticed because setup-ruby's bundler cache satisfied the entire lockfile, so bundle install never re-resolved and never read that gemspec. Any PR that touches a rubygems-sourced gem forces a real resolve on the 3.2 runner and trips over it — which is what #213 (rubocop 1.89.0) did. Its test (3.3) failure is only matrix fail-fast, not a real failure.

Fix

1. Gate the dependency on Ruby >= 3.3 (Gemfile). Nothing in the suite needs the official SDK:

• spec_helper.rb's require 'openai' resolves to ruby-openai — both gems ship lib/openai.rb.
• spec/integration/openai_mcp_integration_spec.rb uses ruby-openai's access_token: API, not the official gem's api_key:.
• The only consumer is examples/openai_ruby_mcp.rb, which unshifts the gem's load path explicitly.

A dev-only example dependency shouldn't dictate the library's supported floor.

2. Install uncached on the 3.2 job (.github/workflows/ci.yml). The guard alone isn't enough — bundler-cache: true makes setup-ruby run bundle config set --local deployment true, and deployment mode requires the Gemfile's dependency list to match Gemfile.lock exactly:

The list of sources changed, but the lockfile can't be updated because frozen mode is set
You have deleted from the Gemfile: * openai

Local .bundle/config beats BUNDLE_* env vars in Bundler's settings precedence, so the job can't opt out of deployment mode via env. The cache is turned off for that one matrix entry instead.

Verification

• Ruby 4.0.6 (unchanged path): Gemfile.lock byte-identical, RuboCop clean, 1701 examples / 0 failures.
• Guard forced false (simulating 3.2): resolution succeeds and is purely subtractive — it drops only the GIT section, openai!, and the two transitive deps unique to it (cgi, connection_pool). No version churn on any other gem. RuboCop clean, 1701 examples / 0 failures.
• Lockfile audit: all 68 rubygems-sourced gems in Gemfile.lock accept Ruby 3.2, so the uncached 3.2 resolve has nothing else it could downgrade.

Trade-offs

• The 3.2 job loses gem caching (~30-60s slower) and resolves instead of replaying the lockfile.
• examples/openai_ruby_mcp.rb will now fail on Ruby 3.2 at Gem::Specification.find_by_name('openai'). Left as-is — the example targets an SDK that genuinely requires 3.3. Happy to add a friendly abort if you want one.

The alternative is to drop Ruby 3.2 entirely (EOL since 2026-03-31, and .rubocop.yml already sets TargetRubyVersion: 3.3.5), which would be simpler but is a breaking change for users.

Once merged, @dependabot rebase on #213 should turn it green.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits.
Credits must be used to enable repository wide code reviews.

[simonx1]

Superseded by a PR that drops Ruby 3.2 support outright instead of working around the OpenAI SDK's 3.3 floor.