# Changelog

## Score

- CAI 70 → 66 (-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 69 → 69 (+0.0)
- Maturity 61 → 56 (-4.6)
- Readiness 71 → 71 (+0.0)
- Security 97 → 97 (+0.0)
- Domain Modelling 100 → 100 (+0.0)

## Resolved (5)

- Inconsistent naming convention for safe vs. unsafe operations. While the bang (!) suffix is a common Ruby convention for raising exceptions vs. returning nil/false, the presence of both forms across different modules (Common and Adapters) without clear documentation on the distinction creates cognitive load. More critically, the parameter signatures differ: Common methods take `args` (likely a hash/options), while Adapter methods take `trackable, options` (positional trackable object). This forces developers to learn two different calling conventions for the same logical operation depending on which layer they are interacting with.
- Inconsistent setter/getter patterns in Config class. `orm` and `enabled` have both setter (`orm=`) and getter (`orm`) methods, but `table_name` only has a method `table_name(name)` which appears to be a setter (or a getter with no args, but the signature implies an arg). This breaks the standard Ruby accessor pattern (`attr_accessor` style) and makes the API unpredictable. Specifically, `table_name` lacks a corresponding `table_name=` or a clear no-arg getter.
- Off-boarding risk: anonymized user #1
- Redundant and inconsistent naming for checking global vs. instance/module-level activity status. `PublicActivity.enabled?` checks the global state, while `Common.public_activity_enabled?` and `Deactivatable.public_activity_enabled?` likely check instance or module-level states. However, the naming `public_activity_enabled?` is verbose and inconsistent with the global `enabled?`. Furthermore, `PublicActivity.enabled=` is a setter, but there is no `PublicActivity.enabled=` counterpart in the instance-level modules, creating an asymmetry in how configuration is applied globally vs. locally.
- Workflow token permissions not restricted

## New (4)

- Inconsistent bang method semantics across modules. In Ruby, the bang (!) suffix typically implies a side effect like raising an exception on failure or mutating state in place. Here, `Common` and `Adapter` both expose `create_activity` and `create_activity!`. However, without seeing the implementation, it is ambiguous whether the bang version raises an exception while the non-bang version returns nil/false, or if they differ in validation strictness. More critically, the parameter names differ (`args` vs `trackable, options`), suggesting different abstraction levels, but the naming convention for the 'strict' variant is duplicated across two distinct layers (Common and Adapter) without clear documentation of the divergence.
- Inconsistent setter/getter naming convention in Config. The `Config` class exposes both setter methods (`orm=`, `enabled=`) and getter-like methods with the same name (`orm`, `enabled`) that accept arguments. In Ruby, a method named `orm` usually implies a getter (no args), while `orm=` is a setter. Having `Config.orm(orm)` suggests it might be a setter or a builder, which conflicts with the standard Ruby convention where `Config.orm` would be a read-only accessor. This creates ambiguity: is `Config.orm(value)` a setter, and `Config.orm` a getter? The presence of explicit `orm=` and `enabled=` setters makes the argument-taking `orm` and `enabled` methods redundant or confusingly named.
- Off-boarding risk: anonymized user #1
- Workflow token permissions not restricted (.github/workflows/main.yml)