# Changelog

## Score

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

## Lenses

- Code Health 94 → 73 (-21.6)
- Architecture 69 → 69 (+0.0)
- Maturity 44 → 38 (-5.3)
- Readiness 65 → 65 (+0.0)
- Security 99 → 99 (+0.0)

## Resolved (6)

- Inconsistent arity and naming convention for execution methods. One takes arguments explicitly, the other does not, despite likely performing the same core action. Additionally, the `!` suffix usually implies a side effect or raising on error, but the lack of arguments in `run!` suggests it might rely on internal state, whereas `run(args)` is explicit. This creates confusion about how to invoke the command.
- Inconsistent method signatures for defining nested hash structures. `ArrayFilter.hash` omits the `name` parameter, while `HashFilter.hash` includes it. This suggests `ArrayFilter` might be using a default name or context, whereas `HashFilter` requires explicit naming, leading to inconsistent API usage patterns for similar structural definitions.
- Off-boarding risk: anonymized user #1
- While getter/setter pairs are common, the method name `error_message_creator` is verbose and slightly ambiguous. It is not immediately clear if this returns a class, an instance, or a callable. However, this is a minor stylistic issue rather than a functional inconsistency.
- While the signatures match, the context differs significantly. `ArrayFilter` defines a model for elements within an array, while `HashFilter` defines a model for a specific key. The method name `model` is overloaded with different semantic meanings (element type vs. key type), which can be confusing when reading code that uses both filters.
- Workflow token permissions not restricted

## New (13)

- Consistent signatures for `model`, but `ArrayFilter` has `model` while `HashFilter` also has `model`. This is consistent. However, `ArrayFilter` has `hash` and `array` methods that differ from `HashFilter`. The inconsistency is specifically in `hash` and `array` methods between these two types.
- Duplicate intent with ambiguous distinction. Two methods exist with nearly identical names (`run` vs `run!`) but different signatures (one takes no args, one takes no args). The `!` suffix usually implies mutation or raising errors, but without seeing bodies, the API surface suggests redundant entry points for execution.
- Inconsistent arity and naming convention for execution methods. One takes arguments, the other does not, despite both being named 'run' variants. This suggests a confusion between 'building' a command with args vs 'executing' it, or a copy-paste error in signature design.
- Inconsistent method signatures for defining nested array structures. `ArrayFilter.array` takes `(options, block)` while `HashFilter.array` takes `(name, options, block)`. The `name` parameter is missing in `ArrayFilter`.
- Inconsistent method signatures for defining nested structures. `ArrayFilter.hash` takes `(options, block)` while `HashFilter.hash` takes `(name, options, block)`. The `name` parameter is missing in `ArrayFilter`, making the API inconsistent for defining nested hash inputs within an array context.
- Off-boarding risk: anonymized user #1
- Orphaned file (lib/mutations/array_filter.rb)
- Orphaned file (lib/mutations/command.rb)
- Orphaned file (lib/mutations/errors.rb)
- Orphaned file (lib/mutations/hash_filter.rb)
- Orphaned file (lib/mutations/string_filter.rb)
- While these are on different types, the naming `message` vs `message_list` is inconsistent across error container types. `ErrorAtom` has both, but `ErrorHash` and `ErrorArray` also have both. However, `ErrorAtom` is a single error, `ErrorHash`/`ErrorArray` are collections. The inconsistency lies in `ErrorAtom` having `message` (singular) and `message_list` (plural), whereas the collection types also have both. This is actually consistent, BUT `ErrorAtom.message()` and `ErrorHash.message()` returning different structures (string vs array of strings?) would be an inconsistency. Assuming they return strings, it's fine. However, `ErrorAtom` having `message_list` is semantically odd for a single atom.
- Workflow token permissions not restricted (.github/workflows/ci.yml)