fix(openfeature): return ResolutionDetails from provider and bump openfeature-sdk to 0.6.5

[jonathannorris]

Summary

• Fixes the provider returning DevCycle::Variable instead of OpenFeature::SDK::Provider::ResolutionDetails, which made every fetch_*_details call raise
• Bumps openfeature-sdk from 0.4.1 to 0.6.5
• Breaking: raises required_ruby_version from >= 3.2 to >= 3.4
• 116 examples, 0 failures

The Problem

The six fetch_*_value methods returned a DevCycle::Variable, which only exposes value. EvaluationDetails' delegators for reason / variant / error_code / flag_metadata had nothing to call:

details FAILED: NoMethodError: undefined method 'reason' for an instance of DevCycle::Variable

This is pre-existing, not a 0.6.5 regression; 0.4.1's EvaluationDetails has the same delegator list. 0.6.5 makes it worse in one way: its type-mismatch path also assigns variant=, which Variable lacks, and its new begin/rescue around evaluate_flag swallows that into a silent default-value return, so the failure is masked instead of raised.

Implementation

The six fetch_*_value methods now delegate to one private resolve helper returning ResolutionDetails with value, reason, and flag_metadata. Reason passes DevCycle's own eval reason through when present, since the vocabulary already overlaps OpenFeature's (DEFAULT, SPLIT, TARGETING_MATCH), falling back based on isDefaulted. eval[:details] and eval[:target_id] are surfaced as flag metadata. The fetch_integer_value .to_i coercion is preserved.

Verified end to end:

TARGETED: value=true reason="SPLIT" meta={details: "Random Distribution | All Users", target_id: "621642332ea68943c8833c4d"}
INT: value=123 (Integer) reason="SPLIT"

Contrary to what I expected going in, the provider was not on a legacy interface. Diffing the 0.4.1 and 0.6.5 gems shows the contract method names and signatures are byte-for-byte identical, and the suite passes on 0.6.5 with zero code changes. The return type was the only real non-conformance.

Notes

The Ruby version bump is forced by upstream: openfeature-sdk 0.6.0+ sets required_ruby_version >= 3.4. Anyone on 3.2 or 3.3 cannot install the next release, and Ruby 3.3 is in maintenance until roughly March 2027, so that is a real audience. The alternative is staying on 0.4.x. I collapsed the CI matrix from ['3.2.0','3.3.0','3.4.1'] to ['3.4.1']; you may want a second entry for real coverage.

error_code is still never populated. Mapping DevCycle's DEFAULT_REASON_DETAILS onto ErrorCode would make fetch_*_details genuinely useful, and is worth a follow-up.