# Changelog

## Score

- CAI 69 → 65 (-4.0)
- Rubric changed (rubric-2026.10.1 → rubric-2026.10.5) — scores are not directly comparable.

## Lenses

- Code Health 100 → 76 (-24.3)
- Architecture 69 → 69 (+0.0)
- Maturity 59 → 55 (-4.7)
- Readiness 74 → 74 (+0.0)
- Security 97 → 97 (+0.0)

## Resolved (5)

- Confusing naming overlap between the integration helper and the matcher. `Enumerize.Integrations.RSpec.enumerize(attr)` appears to be a helper for defining enumerized attributes in tests or setting up the test environment, while `Matcher.in` is the actual assertion. The name `enumerize` in the RSpec integration context is ambiguous compared to the main DSL.
- Inconsistent method signatures for the same operation. `ActiveRecordSupport`'s `reload` accepts an `options` argument, while `MongoidSupport`'s `reload` takes no arguments. This forces consumers to handle backend-specific signatures for a standard ORM operation.
- Redundant instance method definitions. Both `ActiveRecordSupport` and `ActiveModelAttributesSupport` define `write_attribute` with the exact same signature. While they may target different backends, the duplication suggests a lack of shared interface or mixin for this common attribute writing behavior.
- Severe duplication of the core API entry point. The `enumerize` method is defined across 9 different types/modules (Support modules, Scope modules, Integrations, Predicates). This creates a confusing surface where it is unclear which module provides the canonical definition or if they are distinct implementations.
- Workflow token permissions not restricted

## New (6)

- Duplicate method signature `write_attribute` in different support modules. Both `ActiveRecordSupport` and `ActiveModelAttributesSupport` expose an instance method with the exact same signature. This suggests either redundant implementation or a lack of clear separation of concerns between ActiveModel and ActiveRecord support layers.
- Inconsistent signature for `reload`. `ActiveRecordSupport` accepts an `options` argument, while `MongoidSupport` does not. This inconsistency forces consumers to handle different argument lists depending on the underlying ORM, violating the principle of least surprise.
- Orphaned file (lib/enumerize/attribute.rb)
- Proliferation of 'enumerize' methods with identical signatures across many types. There are at least 11 different types exposing a method named `enumerize` (or similar) that takes `(name, options)` or `(attr)`. This creates significant confusion about which method is the 'primary' API entry point and which are internal or integration-specific implementations. `Enumerize.Base.ClassMethods.enumerize` is likely the core, but it is not clearly distinguished from the support/integration layer methods.
- Redundant and scattered 'included' hooks. The API exposes multiple distinct types/methods named 'included' across different namespaces (Enumerize, Base, Module, ModuleAttributes, Sequel.Plugins). It is unclear if these are separate extension points or if they represent a single conceptual hook that has been fragmented across the codebase. Specifically, `Enumerize.included` vs `Enumerize.Base.included` suggests a duplication of intent for module inclusion.
- Workflow token permissions not restricted (.github/workflows/ruby.yml)