# Changelog

## Score

- CAI 66 → 68 (+1.8)
- Rubric changed (rubric-2026.09.8 → rubric-2026.09.16) — scores are not directly comparable.

## Lenses

- Code Health 100 → 100 (+0.0)
- Architecture 100 → 96 (-3.8)
- Maturity 59 → 59 (+0.0)
- Readiness 67 → 69 (+1.7)
- Security 62 → 70 (+7.5)

## Resolved (2)

- Documentation: no installation or build instructions (README.md)
- Off-boarding risk: anonymized user #1

## New (4)

- Inconsistent Key Import/Creation API: `JWK.create_from` is a factory method on the `JWK` type that likely dispatches to specific types (EC, RSA, HMAC). However, each specific type (EC, RSA, HMAC) also has an `import` method. It is unclear if `create_from` and `import` do the same thing or if `import` is for JWK-formatted data while `create_from` is for raw keys. The existence of both factory-style and instance-style import methods on different levels of the hierarchy is inconsistent.
- Inconsistent Verification Granularity and Signature: `EncodedToken` exposes both high-level verification (`verify!`, `valid?`) that takes `signature` and `claims` (which seems to imply passing the raw signature bytes and the decoded claims hash), AND low-level verification methods (`verify_signature!`, `verify_claims!`) that take specific keys/algorithms/options. The high-level methods' parameters (`signature`, `claims`) are ambiguous compared to the explicit nature of the low-level methods. Furthermore, `verify!` vs `valid?` is a standard pattern, but mixing it with `verify_signature!` (which takes algorithm/key) and `verify_claims!` (which takes options) creates a fragmented API where the user must choose between a 'black box' verify and a 'white box' verify without clear distinction in intent.
- Off-boarding risk: anonymized user #1
- Redundant/Overlapping Verification Logic: The top-level `JWT.decode` method performs verification internally (based on the `verify` arg and `options`). However, `JWT.Claims` exposes a separate, lower-level API (`verify_payload!`, `valid_payload?`, `payload_errors`) that performs the exact same claim validation logic. This creates two entry points for the same operation: one high-level convenience method and one low-level component method, leading to confusion about which to use for custom verification flows.

## Changes since last survey

- 4 commits — 4 feature/other, 0 fixes

## By area

- (root) — 3 commits
- .github/workflows — 1 commit

## Notable commits

- change: Bump ruby/setup-ruby from 1.321.0 to 1.324.0 (#765)
- change: Document the actual release process (#764)
- change: Prepare the next version iteration (#763)
- change: Prepare the v3.3.0 release (#762)