# Changelog

## Score

- CAI 61 → 58 (-2.6)
- Rubric changed (rubric-2026.10.1 → rubric-2026.10.5) — scores are not directly comparable.

## Lenses

- Code Health 77 → 64 (-13.6)
- Architecture 98 → 98 (+0.0)
- Maturity 53 → 51 (-2.2)
- Readiness 55 → 55 (+0.0)
- Security 75 → 77 (+2.3)
- Performance 80 → 80 (+0.0)

## Resolved (7)

- Ambiguous method signature for `exists?`. The method is defined twice: once taking an `id` and options, and once taking no arguments. It is unclear if the no-argument version checks for the existence of any record, or if it is a validation helper. This overloading is inconsistent with typical REST resource patterns where existence is usually tied to a specific identifier.
- Documentation: hard to navigate
- Duplicate query entry points with ambiguous scope. `Base.where` and `Base.all` exist as class methods on the resource, but `WhereClause` also exposes `where` and `all`. It is unclear if `Base.where` returns a `WhereClause` or executes immediately, and if `WhereClause.all` is a distinct operation from `Base.all`. This creates confusion about whether the API is lazy-evaluated or eager-evaluated at different levels.
- Inconsistent parameter usage for destruction. `Base.destroy` takes an optional `path` (likely overriding the default element path), while `Singleton.destroy` also takes a `path`. However, `Singleton` resources typically have a fixed path (e.g., `/settings`), making the `path` argument redundant or confusing. If `Singleton` is a subclass of `Base`, the signature should be consistent, or `Singleton` should ignore the `path` argument with a clear contract.
- Off-boarding risk: anonymized user #1
- PR-triggered workflow without a permissions block
- Redundant naming for bulk updates. `update` and `update_attributes` appear to perform the same bulk update operation (accepting a hash of attributes). In many ORMs, `update_attributes` is an alias for `update`, but exposing both as distinct public methods without clear differentiation (e.g., one raising exceptions, one returning boolean) is confusing.

## New (7)

- Ambiguous method signature. The method 'exists?' is overloaded to check for the existence of a specific record by ID (instance method with args) and potentially the existence of any record or a class-level check (instance method with no args). This is confusing because 'exists?' is typically a class method in ORMs, and using it as an instance method with different arities for different semantics is poor API design.
- Duplicated block (9 lines × 2) (examples/performance.rb)
- Inconsistent naming for single-attribute updates. 'update_attribute' (singular) updates one field, while 'update_attributes' (plural) and 'update' update multiple. The singular/plural distinction is clear, but 'update_attribute' bypasses validations while 'update' does not (typically). This behavioral difference combined with the naming makes it easy to misuse. However, the primary inconsistency is the mix of singular/plural naming conventions for similar bulk/single operations.
- Off-boarding risk: anonymized user #1
- Orphaned file (lib/active_resource/collection.rb)
- PR-triggered workflow without a permissions block (.github/workflows/rubocop.yml)
- Redundant naming for identical operations. Both methods accept a hash of attributes and perform the same save operation. 'update_attributes' is the legacy Rails naming convention, while 'update' is the modern standard. Having both creates confusion about which to use.