# Changelog

## Score

- CAI 75 → 71 (-4.7)
- Rubric changed (rubric-2026.10.1 → rubric-2026.10.5) — scores are not directly comparable.

## Lenses

- Code Health 97 → 74 (-23.1)
- Architecture 96 → 96 (+0.7)
- Maturity 64 → 61 (-3.3)
- Readiness 75 → 75 (+0.0)
- Security 94 → 94 (+0.0)

## Resolved (6)

- Ambiguous accessor names. `dollars()` suggests it returns a value in dollars, but `Money` is currency-agnostic. If the object is EUR, `dollars()` is misleading. `amount()` is generic but doesn't specify the unit (cents vs fractional). This conflicts with `cents()` and `fractional()` which are explicit.
- Ambiguous distinction between `to_money` and `exchange_to`. `to_money` might imply conversion (exchange) or just wrapping/creating a new instance with a different currency context without actual rate-based conversion. The naming does not clearly distinguish between 'convert value using rates' and 'change currency context'.
- Duplicate operations with different naming conventions. One uses the verb 'round' and the other uses 'to_nearest'. They likely perform the same rounding logic based on currency smallest denomination.
- Inconsistent currency conversion API. `exchange_to` is generic, while `as_*` methods are hardcoded to specific currencies. This forces users to know specific methods for common currencies rather than using a generic exchange mechanism, or vice versa.
- Off-boarding risk: anonymized user #1
- Redundant constructors with ambiguous intent. `from_dollars` implies a specific unit (dollars) but accepts a generic `currency` argument, which is confusing. It is unclear if `from_dollars` forces USD or if it's just a naming alias for `from_amount`. Given `Constructors.us_dollar` exists, `from_dollars` is likely a legacy or poorly named alias.

## New (6)

- Duplicate methods with different names performing the same operation. One is a verb-noun phrase (`round_to...`) and the other is a noun-verb phrase (`to_nearest...`), but both imply rounding to the smallest denomination.
- Inconsistent API for currency conversion. `exchange_to` is generic, while `as_*` methods are hardcoded to specific currencies. This forces users to use different methods depending on whether they want a generic conversion or a specific one, rather than a unified `convert_to(currency)` interface.
- Inconsistent accessor naming for numeric values. `dollars()` and `amount()` likely return the same float/decimal representation, while `cents()` and `fractional()` likely return the same integer representation. Having two names for the same concept (e.g., `dollars` vs `amount`) creates confusion about which to use.
- Off-boarding risk: anonymized user #1
- Redundant constructors with ambiguous intent. `from_dollars` implies a specific unit (dollars) but accepts a generic `currency` argument, which is confusing. It duplicates the functionality of `from_amount` but with a misleading name that suggests it only works for USD.
- While these are polymorphic implementations, the naming `exchange_with` is slightly inconsistent with the general `Money` object method `exchange_to`. The Bank methods take `from` and `to` explicitly, whereas the Money method takes `other_currency` (implying `from` is self). This is a minor inconsistency in argument semantics between the domain objects.