# Changelog

## Score

- CAI 68 → 63 (-4.8)
- Rubric changed (rubric-2026.10.1 → rubric-2026.10.5) — scores are not directly comparable.

## Lenses

- Code Health 98 → 75 (-23.5)
- Architecture 100 → 100 (+0.0)
- Maturity 55 → 50 (-5.2)
- Readiness 67 → 67 (+0.0)
- Security 82 → 82 (+0.0)

## Resolved (4)

- Duplicate method name `soap_header` with identical signatures but different scopes (Global vs Local). While technically distinct by receiver, this naming convention forces users to remember context-specific method names for the same concept, rather than using a unified configuration pattern (e.g., `headers` or `soap_header` with scope resolution).
- Inconsistent predicate naming for error states. `success?` is a positive assertion, while `soap_fault?` and `http_error?` are negative assertions. Furthermore, `http_error?` overlaps with `HTTPError.present?` in intent (checking for HTTP errors), but the API surface exposes both a method on Response and a class method on HTTPError.
- Off-boarding risk: anonymized user #1
- Redundant entry points for executing an operation. `Client.call` acts as a facade that likely delegates to `Operation.call`, but both are exposed as public API methods for the same intent (executing a SOAP operation). This creates confusion about whether the user should interact with the Client or the Operation object directly.

## New (5)

- Ambiguous naming convention for similar data extraction methods. It is unclear what the distinction between `hash` and `full_hash` is without documentation (e.g., one might include metadata, the other only the body). This violates the principle of least surprise.
- Confusingly similar query methods. `find` likely wraps `xpath` or uses a simplified syntax, but the existence of two methods for querying the response body with a path-like argument is inconsistent with standard XML parsing APIs which usually stick to `xpath` or `css`.
- Off-boarding risk: anonymized user #1
- Redundant entry points for the same core action. `Client.call` acts as a facade that delegates to `Operation.call`. Exposing both creates confusion about whether the user should interact with the Client or the Operation directly.
- Redundant request building operations. `Client.build_request` is a convenience wrapper around `Client.operation(name).build(...)`. This duplicates the intent of constructing a request object.

## Changes since last survey

- 1 commits — 1 feature/other, 0 fixes

## By area

- .github/workflows — 1 commit

## Notable commits

- change: Bump ruby/setup-ruby from 1.327.0 to 1.328.0