# Changelog

## Score

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

## Lenses

- Code Health 98 → 75 (-23.6)
- Architecture 94 → 94 (+0.0)
- Maturity 69 → 65 (-3.6)
- Readiness 72 → 72 (+0.0)
- Security 59 → 59 (+0.0)
- Performance 90 → 90 (+0.0)

## Resolved (4)

- Duplicate parsing/analysis operations. Phonelib.Core.parse and Phonelib.PhoneAnalyzer.analyze appear to perform the same core function: taking a raw phone string and an optional country to produce a structured result (likely a Phone object). Having two entry points for the same transformation is confusing.
- Inconsistent naming for getter/setter pair. While Ruby allows using the same name for getter and setter with assignment, the explicit separation here is fine, but it conflicts with the general pattern of the library where other properties might not follow this strictly. However, the bigger issue is that `default_country` is a global state modifier on Core, while most other operations are instance-based on Phone. This is a design inconsistency rather than a naming one, but it contributes to API confusion.
- Redundant country-specific validation on Core vs Phone. Similar to the general validation issue, Phonelib.Core exposes valid_for_country? and invalid_for_country? which duplicate the Phone instance methods. The Core methods take the phone number as an argument, while the Phone methods operate on the instance's internal number.
- Redundant validation methods on Core vs Phone. The Core class exposes instance-level validation methods (valid?, invalid?, possible?, impossible?) that duplicate the functionality of the Phone instance methods. Users can validate a phone number by calling Phonelib.Core.valid?(number) or by instantiating a Phone object and calling phone.valid?. This creates two parallel APIs for the same intent.

## New (4)

- Ambiguous naming for data accessors. `phone_data`, `data_by_country_codes`, and `phone_ext_data` all appear to expose internal data structures. The naming convention is inconsistent (`phone_data` vs `data_by_...` vs `phone_ext_...`). It is unclear if these are meant for public consumption or internal use. If public, they should follow a consistent naming pattern (e.g., `get_phone_data`, `get_country_data`).
- Documentation: no architecture or design documentation
- Duplicate validation logic across Core and Phone types. Core provides class-level validation methods that accept a phone string, while Phone provides instance-level methods. While technically distinct (class vs instance), the naming `valid?`/`invalid?` is identical, which can confuse users about whether they are calling a static utility or an instance method. More critically, `Phonelib.Core.valid_for_country?` and `Phonelib.Phone.valid_for_country?` create a parallel API surface where the user must choose between the 'Core' entry point and the 'Phone' object entry point for the same logical operation.
- Semantic overlap between `Core.parse` and `PhoneAnalyzer.analyze`. Both accept a phone string and an optional country and likely return similar structured data or a Phone object. The distinction between 'parsing' (converting string to object) and 'analyzing' (determining properties) is blurred here. If `Core.parse` returns a `Phone` object, `PhoneAnalyzer.analyze` seems redundant unless it returns a different, more detailed structure. If it returns the same structure, it is a duplicate operation with a confusingly different name.

## Changes since last survey

- 2 commits — 2 feature/other, 0 fixes

## By area

- (root) — 1 commit
- data/extended_data.dat — 1 commit

## Notable commits

- change: bumped version
- change: updated data

## Architecture

- 0 containers · 1 bounded contexts · 0 dependency edges (baseline)