# Changelog

## Score

- CAI 70 → 64 (-5.8)
- Rubric changed (rubric-2026.10.1 → rubric-2026.10.5) — scores are not directly comparable.

## Lenses

- Code Health 89 → 70 (-19.4)
- Architecture 100 → 100 (+0.0)
- Maturity 55 → 50 (-5.2)
- Readiness 79 → 79 (+0.0)
- Security 84 → 84 (+0.0)
- Performance 90 → 90 (+0.0)

## Resolved (9)

- Duplicate method names with different parameter names suggest copy-paste errors or lack of refactoring. While parameter names don't affect runtime behavior in many languages, they indicate internal inconsistency in the API definition.
- Duplicate method names with different parameter names, same as above.
- Duplicate method names with different parameter names.
- Duplicate method names with different parameter names.
- Inconsistent argument types for 'merge' operations. One takes a Hash, the other takes a URI object. This forces the user to know the type of the input to call the correct method, rather than having a single 'merge' method that handles both or clearly named methods like 'merge_with_uri' and 'merge_with_hash'.
- Off-boarding risk: anonymized user #1
- Standard Ruby convention for mutable vs immutable operations. However, combined with 'join' vs 'join!' and 'merge' vs 'merge!' and 'omit' vs 'omit!', the API has many pairs. While consistent with Ruby conventions, the sheer number of duplicated operations with only a bang suffix can be verbose. More critically, 'normalize' returns a new URI, while 'normalize!' modifies in place. This is consistent, but 'join' and 'join!' have different signatures (arity), which breaks the pattern.
- The non-bang 'merge' takes a Hash, while the bang 'merge!' takes a URI. This is highly confusing. Typically, the bang version is the mutable counterpart to the non-bang version with the same signature. Here, the signatures differ, making it unclear which method to use for a given input type.
- Two methods named 'join' with different signatures (one takes multiple URIs, one takes a single URI). This is ambiguous for callers who might not check arity carefully, especially in dynamic languages or when using splats.

## New (7)

- Duplicate method names with different parameter names, identical to the `to_ascii` issue above.
- Duplicate method names with different parameter names, suggesting potential copy-paste errors or lack of refactoring. While Ruby allows parameter name changes, having two methods with the exact same name and arity in the same class is a syntax error in most languages or indicates a severe documentation/API generation artifact. If this is Ruby, it's a redefinition. If it's a static analysis of a generated API, it's a clear redundancy.
- Duplicate method names with different parameter names. Same issue as above.
- Duplicate method names with different parameter names. The parameter name `value` vs `unicode` suggests the same operation is defined twice, likely due to code duplication or poor API generation.
- Inconsistent argument types for `merge` and `merge!`. `merge` takes a `hash` (key-value pairs) while `merge!` takes a `uri` (another URI object). This is a significant semantic inconsistency. Usually, `merge` and `merge!` should have the same signature, differing only in mutability. Here, they operate on different data structures.
- Off-boarding risk: anonymized user #1
- Two instance methods named `join` with different arities (one takes multiple URIs, one takes a single URI). While Ruby supports method overloading via arity, this is often confusing for users expecting consistent behavior. More critically, `URI.join` is also a class method (static) in many URI libraries, but here it appears as an instance method. If `URI.join(uris)` is intended to be a class method (static) and `uri.join(other)` is an instance method, the signature listing is ambiguous. However, looking at the list, `URI.join(uris)` is listed under `type Addressable.URI` which usually implies instance methods in this format, but `URI.parse` is also there. If `join` is both a class and instance method, the signature list is incomplete or misleading. Assuming these are both instance methods, having two `join` methods is an inconsistency in naming convention (singular vs plural argument implying different semantics).