# Changelog

## Score

- CAI 61 → 62 (+1.0)

## Lenses

- Code Health 75 → 75 (+0.0)
- Architecture 88 → 86 (-1.4)
- Maturity 56 → 56 (+0.0)
- Readiness 52 → 53 (+1.3)
- Security 79 → 85 (+5.9)
- Domain Modelling 100 → 100 (+0.0)

## Resolved (10)

- Confusing overlap between `promote` and `promote_derivatives`. `promote` in the Derivatives plugin seems to handle the entire promotion process including derivatives, while `promote_derivatives` suggests a subset. Additionally, `promote_cached` and `promote_background` in Backgrounding plugin overlap in intent (promoting a cached file) but differ in execution mode (sync vs async), which is clear, but the naming `promote` vs `promote_derivatives` is ambiguous regarding scope.
- Inconsistent naming for endpoint generation methods. Some plugins use `*_endpoint` (singular noun) while others use `*_endpoint` but the context implies different responsibilities (derivation vs download vs presign). More critically, `DerivationEndpoint` and `DownloadEndpoint` have parallel structures but different method names (`derivation_endpoint` vs `download_endpoint`) and argument signatures, making it hard to predict how to add a new endpoint type.
- Inconsistent naming for removal operations. `remove_derivative` vs `remove_derivatives` vs `delete_derivatives`. The distinction between 'remove' and 'delete' is not obvious (does one just remove from the hash and the other also delete from storage?).
- Multiple destroy methods with unclear scope. `destroy` on the Attacher might destroy the file, the derivatives, or the record association depending on the plugin context. `destroy_attached` and `destroy_previous` suggest different targets (current vs old). This creates a high cognitive load for developers trying to clean up resources.
- No SBOM
- No artifact signing
- No build provenance
- PR-triggered workflow without a permissions block
- Redundant methods for adding and uploading derivatives. `add_derivative` vs `add_derivatives` and `upload_derivative` vs `upload_derivatives` are simple singular/plural variants, but the existence of both `add` and `upload` methods suggests a split in responsibility that isn't clearly defined (e.g., does `add` just modify the hash, while `upload` persists to storage?).
- Unpinned build actions

## New (1)

- PR-triggered workflow without a permissions block (.github/workflows/ci.yml)

## Changes since last survey

- 4 commits — 3 feature/other, 1 fixes

## By area

- (root) — 2 commits
- lib/shrine — 1 commit
- test/plugin — 1 commit

## Notable commits

- fix: Fix all warnings triggered in tests
- change: Drop support for Ruby 3.2
- change: Remove unused response variable from S3 encrypted downloads (#757)
- change: Stop testing the deprecated ruby-filemagic MIME type analyzer

## Architecture

- Unchanged — 0 containers · 1 contexts · 0 edges