# Changelog

## Score

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

## Lenses

- Code Health 66 → 53 (-12.8)
- Architecture 92 → 92 (+0.6)
- Maturity 72 → 68 (-4.5)
- Readiness 67 → 67 (-0.1)
- Security 82 → 37 (-45.2)
- Domain Modelling 100 → 100 (+0.0)
- Accessibility 52 → 31 (-20.9)
- Performance 95 → 95 (+0.0)

## Resolved (6)

- Ambiguous overlap between `locked()` and `locked_jids()`. It is unclear if `locked()` returns a boolean status or a list of IDs. If it returns IDs, it duplicates `locked_jids`. If it returns a boolean, the naming convention is inconsistent with other status checks like `enabled?()`.
- Duplicate intent for checking lock status across different types. `Locksmith.locked?` and `Lock.locked` (if boolean) serve the same purpose but are accessed via different objects (the manager vs the lock entity).
- PR-triggered workflow without a permissions block
- Parallel structures with similar names (`LockTTL` vs `LockTimeout`) and identical method signatures (`calculate()`). This suggests a potential duplication of logic or a need for a unified interface if they are used interchangeably.
- Potential semantic confusion between `ttl` (Time To Live) and `timeout`. In Redis/Locking contexts, these are often related but distinct concepts (expiration vs. wait time). However, without clear documentation, users may confuse which setter/getter controls which behavior.
- Redundant deletion methods with ambiguous semantics. In Ruby, the `!` suffix often implies a more aggressive or destructive action, but here both methods likely perform the same deletion operation. Having both creates confusion about whether one is a no-op or has different side effects.

## New (12)

- Ambiguous duplication: It is unclear if `now_f` and `now` serve distinct purposes (e.g., float vs integer timestamp, or different time sources) or if one is a legacy alias for the other. Without documentation, these appear to be redundant operations for retrieving the current time.
- Ambiguous duplication: `locked` likely returns a boolean indicating if the lock is held, while `locked_jids` returns the IDs of jobs currently holding the lock. However, the naming `locked` is a predicate, while `locked_jids` is a data retrieval method. This is not strictly an inconsistency, but if `locked` returns a list of JIDs in some contexts, it would be a major issue. Assuming standard usage, this is likely consistent, but the naming `locked` vs `locked_jids` could be clearer (e.g., `is_locked?` vs `holding_job_ids`).
- Ambiguous duplication: `reflections` (plural) suggests retrieving a collection or registry of reflections, while `reflect` (singular) suggests performing an action or retrieving a single item. However, without seeing the return types, it is unclear if `reflect` is a method on a specific object or a class method that does something entirely different. If `reflect` is a class method that triggers a reflection process, it's distinct. If it's meant to be a getter for a single reflection, the naming is inconsistent with `reflections`.
- High CVE: [GHSA redacted] (myapp/bun.lock)
- Medium CVE: [GHSA redacted] (myapp/bun.lock)
- Outdated: docs-kit
- Outdated: json
- Outdated: thruster
- PR-triggered workflow without a permissions block (.github/workflows/lint.yml)
- PR-triggered workflow without a permissions block (.github/workflows/rspec.yml)
- Standard Ruby convention violation: Similar to `validate_worker`, the `!` suffix on `delete` implies a destructive operation or raising an exception. If `delete` returns a boolean and `delete!` raises, this is consistent. However, in many Ruby libraries, `delete` is the primary method and `delete!` is not used, or vice versa. Having both requires strict adherence to the convention to avoid confusion.
- Standard Ruby convention violation: The `!` suffix typically implies a destructive operation or raising an exception on failure, while the non-`!` version returns a boolean or nil. However, in validation contexts, this distinction is often confusing if both raise or both return booleans. If `validate_worker` returns a boolean and `validate_worker!` raises, this is consistent with Ruby, but if they behave similarly, it's redundant.

## Changes since last survey

- 1 commits — 1 feature/other, 0 fixes

## By area

- .claude/commands — 1 commit

## Notable commits

- change: chore(claude): move the workflow onto the shared flow plugin (#1012)

## Architecture

- 0 containers · 1 bounded contexts · 0 dependency edges (baseline)