# Changelog

## Score

- CAI 55 → 56 (+0.8)
- 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 33 → 39 (+5.3)
- Readiness 67 → 67 (+0.0)
- Security 94 → 94 (+0.0)

## Resolved (3)

- Duplication of serialization logic between Config and Manager. The Manager delegates to or uses the Config's serialization blocks, but exposes identical method signatures. This forces users to choose between two entry points for the same underlying operation, creating ambiguity about which is the 'source of truth' for session handling.
- While the suffixes (?/!) follow Ruby conventions for boolean return vs exception raising, the base name 'authenticate' is overloaded with three distinct control-flow behaviors. In a strict API consistency review, this creates cognitive load regarding which method to use for non-blocking checks vs. blocking assertions. However, this is idiomatic Ruby.
- Workflow token permissions not restricted

## New (9)

- Orphaned file (lib/warden/config.rb)
- Orphaned file (lib/warden/hooks.rb)
- Orphaned file (lib/warden/manager.rb)
- Orphaned file (lib/warden/proxy.rb)
- Orphaned file (lib/warden/strategies/base.rb)
- The method `user` takes an optional `argument` which likely acts as a scope or key, while `set_user` takes a user object and options. This creates two different ways to interact with the current user's identity: one for retrieval (with scope) and one for assignment. This is not strictly redundant but inconsistent in parameter handling for user-centric operations.
- The naming `custom_failure!` and `custom_failure?` is ambiguous. `custom_failure?` likely checks if a custom failure was set, while `custom_failure!` sets it. However, the `!` suffix usually implies mutation, and `?` implies a query. This is consistent with Ruby conventions, but the term 'custom_failure' is vague compared to 'failure_reason' or 'failure_handler'.
- While the Ruby convention of `?`, `!`, and bare methods is standard, the specific semantics of `authenticate` vs `authenticate?` vs `authenticate!` are often confused by users. `authenticate` typically returns the user or nil, `authenticate?` returns a boolean, and `authenticate!` raises an error. This is a high-cognitive-load API surface for authentication flows.
- Workflow token permissions not restricted (.github/workflows/ruby.yml)