Stale rubocop-rspec and rspec-rails entries crash rake rubocop on Ruby 3.3 #68

The Rakefile requires rubocop-rspec for the rubocop task (Rakefile:45) and the Gemfile pulls in both rspec-rails ~>6.0 (Gemfile:13) and rubocop-rspec ~>2.22 (Gemfile:18). Neither belongs here: test/zold/test_wts.rb is plain Minitest, no spec/ directory exists, and .rubocop.yml does not enable any RSpec cop. The two gems and the require are dead weight kept from a copy-pasted skeleton.

On the Ruby 3.3 CI runner the version pin resolves rubocop-rspec 2.31.0, which transitively loads rubocop-rspec_rails 2.29.1. That extension calls RuboCop::ConfigLoader.inject_defaults! against the resolved rubocop 1.87.0, and the new signature rejects the directory argument: the rake step prints warning: Use config YAML file path instead of project root directory. and raises out of rubocop-rspec_rails.rb:18. The whole test (ubuntu-24.04, 3.3) job dies after a clean Minitest run of 10 assertions, so the rake.yml workflow stays red on master at 7c79029 and on every open pull request including #62 and #64. CI failure unrelated to actual code makes badge-driven review useless and lets a real regression slip past the reviewer.

Delete gem 'rspec-rails', '~>6.0', require: false and gem 'rubocop-rspec', '~>2.22', require: false from Gemfile, and drop the task.requires << 'rubocop-rspec' line from Rakefile. Run bundle update && bundle exec rake to confirm minitest plus the remaining rubocop-rake, rubocop-minitest, rubocop-performance cops complete cleanly, then re-trigger the workflow so the rake job lands green.