# Changelog

## Score

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

## Lenses

- Code Health 100 → 76 (-24.2)
- Architecture 100 → 100 (+0.0)
- Maturity 55 → 54 (-1.3)
- Readiness 75 → 75 (+0.0)
- Security 97 → 97 (+0.0)

## Resolved (3)

- Ambiguous constructor usage and redundant apply signatures. The constructor takes `input`, but `apply` also accepts `input`. It is unclear if `initialize` is required before `apply`, or if `apply` can be called on a fresh instance without initialization. Having `apply` accept an argument while the constructor also accepts the primary data source suggests a confusing API surface where the state management is unclear.
- Off-boarding risk: anonymized user #1
- Workflow token permissions not restricted

## New (5)

- Ambiguous relationship between `transform` and `transform_partial`. It is unclear if `transform_partial` is a subset of `transform`, a different mode, or if they are mutually exclusive steps in a pipeline. Without documentation, it's hard to know if `transform` calls `transform_partial` internally or if they are distinct operations. If `transform` is the main entry point, `transform_partial` suggests an internal implementation detail leaking into the public API.
- Inconsistent initialization pattern. Most classes use `initialize` to set up state and `apply`/`transform`/`inline` to perform the main operation. However, `Deduplicator` accepts the input in `initialize` but also has an `apply` method that can take the input again (or take no arguments if state was set). This creates ambiguity: should the caller pass data to `initialize` or `apply`? Other classes like `Inliner` or `MarkupImprover` take dependencies in `initialize` and the data in the action method.
- Inconsistent naming convention for conversion methods. Ruby convention typically uses `to_a` for array conversion. `ProviderList` uses `to_ary` which is less common for public API exposure (usually `to_a` is the expected interface for implicit conversion or explicit array casting). While `to_ary` is technically correct for duck-typing arrays, `to_s` is standard. The mix of `to_ary` and `to_s` is fine, but `to_ary` is often a source of confusion compared to `to_a`. However, the bigger issue is that `ProviderList` is a collection wrapper, and having `to_ary` is specific. Let's look for a clearer inconsistency.
- Off-boarding risk: anonymized user #1
- Workflow token permissions not restricted (.github/workflows/main.yml)