# Changelog

## Score

- CAI 62 → 55 (-6.9)
- Rubric changed (rubric-2026.10.1 → rubric-2026.10.5) — scores are not directly comparable.

## Lenses

- Code Health 99 → 75 (-23.7)
- Architecture 95 → 92 (-2.9)
- Maturity 57 → 45 (-12.3)
- Readiness 60 → 60 (+0.0)
- Security 80 → 80 (+0.0)
- Accessibility 57 → 57 (+0.0)

## Resolved (4)

- Ambiguous data retrieval methods with overlapping intents. `data` and `rows` likely return similar collections (arrays of rows/assets), while `data_hash` returns a hash structure. `row_for` retrieves a single row. The distinction between `data` and `rows` is unclear from signatures alone, and `data_hash` suggests a different return type for the same underlying data source.
- Duplicate value resolution logic. `Column` has instance methods `data_value` and `html_value`. `Columns` (the container) also has `data_value` and `html_value` that take a `column_name` instead of a `Column` object. This duplicates the resolution logic and creates two ways to get the same result.
- Inconsistent naming for filter retrieval and application. `filter_value` takes a filter object, while `filter_value_as_string` takes a name. `filter_by_name` and `filter_by` suggest setting or retrieving filters but have ambiguous return types and intents compared to the explicit `filter_value` methods.
- Redundant column lookup methods. `column_by_name` exists on both the instance (`Columns`) and class (`ClassMethods`). Additionally, `find_column_by_name` exists in `ClassMethods` with an explicit `columns` argument, while `column_by_name` in `ClassMethods` does not show arguments, implying it might use an internal state or default. This creates confusion about which method to use for lookup.

## New (5)

- Ambiguous data retrieval methods with overlapping intents. `data` and `rows` appear to return collections of row data, while `data_hash` returns a hash representation. `row_for` retrieves a single row. The distinction between `data` and `rows` is unclear, and `data_hash` suggests a serialization format that might be better served by a single `to_hash` or `as_json` method consistent with `Core#as_json`.
- Duplicate value retrieval logic at both Column and Columns levels. `Column#data_value` and `Columns#data_value` do the same thing. Similarly for `html_value`. This duplication increases maintenance burden and risk of inconsistency.
- Excessive and confusingly similar methods for retrieving filter options. `select_options`, `select_choices`, `select_all`, and `select_values` all seem to retrieve data for dropdowns or lists, but the distinction between them is not clear from the signatures. This creates a high cognitive load for API users.
- Inconsistent naming and argument types for filter value retrieval. `filter_value` takes a filter object, while `filter_value_as_string` takes a name (string). This forces the caller to know whether they have a filter object or just a name, and the return types (raw value vs string) are not immediately obvious from the method names alone.
- Redundant lookup methods for columns. `column_by_name` exists on both the instance and class methods. Additionally, `find_column_by_name` exists on ClassMethods, suggesting an internal or alternative lookup mechanism that duplicates the intent of `column_by_name`.