Hash#transform_keys core monkey-patch breaks the native mapping-hash form (transform_keys(hash))

[rajdeep26]

lib/core_ext/stringify_keys.rb redefines Hash#transform_keys with a block-only (0-arity) implementation (commented "Stolen from ActiveSupport"):

class Hash
  def transform_keys
    return enum_for(:transform_keys) { size } unless block_given?
    result = {}
    each_key { |key| result[yield(key)] = self[key] }
    result
  end
end

Since Ruby 2.5, Hash#transform_keys is a native method that also accepts a mapping hash — { a: 1 }.transform_keys(a: :b) # => { b: 1 }. Requiring json_logic globally overrides that native method for the entire process, so any downstream transform_keys(mapping) call raises:

ArgumentError: wrong number of arguments (given 1, expected 0)

Reproduction

require 'json_logic'
{ a: 1 }.transform_keys(a: :b)
# => ArgumentError: wrong number of arguments (given 1, expected 0)

Real-world impact

This is not hypothetical — it breaks other gems that rely on the native contract. For example, the official anthropic Ruby SDK (>= ~1.46) remaps request headers via headers.transform_keys(header_params), so every streaming request crashes once json_logic is loaded in the same process. Any app or gem using the mapping-hash form hits the same wall, and because it mutates a core class globally it's very hard to trace back to this gem.

Suggested fix

The core monkey-patch isn't necessary — the gem only needs stringify_keys internally, which can be a private helper (or each_with_object) without touching core Hash:

hash.each_with_object({}) { |(k, v), out| out[k.to_s] = v }

If the patch must stay, it should preserve the native contract by delegating to the original for the argument form.

Environment: json_logic 0.4.7, Ruby 3.4.9.