# Changelog

## Score

- CAI 56 → 54 (-1.4)
- Rubric changed (rubric-2026.10.1 → rubric-2026.10.5) — scores are not directly comparable.

## Lenses

- Code Health 99 → 75 (-23.9)
- Architecture 84 → 96 (+12.0)
- Maturity 55 → 55 (+0.0)
- Readiness 36 → 36 (+0.0)
- Security 84 → 83 (-1.0)
- Domain Modelling 100 → 100 (+0.0)

## Resolved (5)

- Asymmetry in recurring task management API. While `schedule` and `unschedule` are consistent with each other, the `RecurringTask` type exposes `create_dynamic_task` and `delete_dynamic_task`. This creates two different naming conventions for the same conceptual operations (creating vs deleting recurring tasks) depending on whether the user interacts via the global `SolidQueue` module or the `RecurringTask` class.
- Documentation: no architecture or design documentation
- Inconsistent batching/iteration semantics for bulk operations. `release_all` implies releasing all claimed executions in the current context. However, `discard` has three variants: `discard_all_in_batches` (explicit batching), `discard_all_from_jobs` (explicit source), and a singular `discard`. The singular `discard` on `ClaimedExecution` likely discards the specific instance, but the naming `discard_all_from_jobs` vs `discard_all_in_batches` is confusingly specific about implementation details (batching) rather than intent. Furthermore, `Execution` type has `discard_all_in_batches` and `discard_all_from_jobs` but no singular `discard` method exposed in the signature list, whereas `ClaimedExecution` does.
- Projects may be oversized for their cohesion
- Workflow token permissions not restricted

## New (4)

- High CVE: [GHSA redacted] (Gemfile.lock)
- Inconsistent method naming and signature for bulk discard operations. `ClaimedExecution` and `Execution` both have `discard_all_in_batches` and `discard_all_from_jobs`, but the signatures differ slightly (`ClaimedExecution.discard_all_in_batches` takes no args implying it operates on the current context, while `Execution.discard_all_in_batches(batch_size)` takes an explicit batch size). This inconsistency in argument requirements for semantically identical operations across related types is confusing.
- Redundant/Confusing naming for recurring task registration. `SolidQueue.schedule_recurring_task` is a high-level convenience method that likely delegates to or is conceptually identical to `RecurringTask.create_dynamic_task`. Having two distinct entry points for the same logical operation (registering a recurring job) creates confusion about which API to use.
- Workflow token permissions not restricted (.github/workflows/main.yml)