# Changelog

## Score

- CAI 62 → 59 (-2.7)
- 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 54 → 52 (-2.8)
- Readiness 53 → 53 (-0.2)
- Security 94 → 94 (+0.0)
- Domain Modelling 100 → 100 (+0.0)

## Resolved (5)

- Duplicate delivery entry points with inconsistent signatures. `Deliverable.deliver` takes an explicit `enqueue_job` boolean and `options`, while `Ephemeral.deliver` takes only `options`. This forces users to understand the internal distinction between 'Deliverable' and 'Ephemeral' contexts to call the correct method, rather than having a unified delivery interface.
- Duplicate query methods for the same state. `read?` and `seen?` likely query the same underlying database column or state flag. Similarly, `unread?` and `unseen?` are redundant. This forces users to guess which predicate method to use.
- Excessive redundancy in state mutation methods. The API exposes both `read`/`unread` and `seen`/`unseen` pairs, each with bang (`!`) and non-bang variants. In most notification systems, 'read' and 'seen' are semantically identical or closely coupled states. Providing 8 distinct methods for what is likely a single state transition (marking as read/seen) creates significant cognitive load and potential for confusion about when to use which term.
- Off-boarding risk: anonymized user #1
- PR-triggered workflow without a permissions block

## New (10)

- Confusingly similar method names with different signatures. `perform_later` and `ephemeral_perform_later` suggest a simple prefix distinction, but they accept different arguments (`event_or_notification` vs `notifier, recipient, params...`), implying different internal mechanisms that are not obvious from the names.
- Duplicate delivery entry points with inconsistent signatures. `Deliverable.deliver` takes an explicit `enqueue_job` boolean, while `Ephemeral.deliver` does not expose this control, forcing users to choose between two different methods for similar intent without a clear distinction in capability.
- Off-boarding risk: anonymized user #1
- Outdated: googleauth
- Outdated: sqlite3
- Outdated: standard
- Outdated: webmock
- PR-triggered workflow without a permissions block (.github/workflows/ci.yml)
- Semantic redundancy and naming confusion. `read`/`unread` and `seen`/`unseen` are often used interchangeably in notification systems, yet both pairs are exposed with bang/non-bang variants. This creates 8 methods for essentially two states (read/unread and seen/unseen), leading to user confusion about which pair to use.
- Workflow token permissions not restricted (.github/workflows/publish_gem.yml)

## Architecture

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