# Changelog

## Score

- CAI 73 → 74 (+1.0)
- Rubric changed (rubric-2026.09.9 → rubric-2026.09.17) — scores are not directly comparable.

## Lenses

- Code Health 89 → 89 (+0.0)
- Architecture 100 → 99 (-1.0)
- Maturity 61 → 61 (+0.1)
- Readiness 87 → 87 (+0.3)
- Security 75 → 81 (+6.3)

## Resolved (3)

- Hotspot: crossbeam-deque/src/deque.rs (crossbeam-deque/src/deque.rs)
- Hotspot: crossbeam-skiplist/src/base.rs (crossbeam-skiplist/src/base.rs)
- Off-boarding risk: anonymized user #1

## New (7)

- Dependency hygiene PARTLY measured — Cargo dependencies read, no committed lock to grade for currency
- Inconsistent naming for blocking vs non-blocking operations. `try_send` is non-blocking, while `send` is blocking. However, the timeout variants are named `send_timeout` and `send_deadline` rather than `send_with_timeout` or similar, creating a slight lexical inconsistency between the base blocking call (`send`) and its timed variants. More critically, `Receiver` uses `recv` (blocking) and `try_recv` (non-blocking), which is consistent with `Sender`, but the timeout methods on `Receiver` are `recv_timeout`/`recv_deadline`. While consistent within the channel module, the mix of `send`/`recv` (blocking) and `try_send`/`try_recv` (non-blocking) is standard, but the lack of a unified `send_with_timeout` pattern makes the API surface feel slightly fragmented between 'try' and 'timeout' naming conventions.
- Inconsistent return types for equivalent operations in SkipList vs SkipMap. `SkipList.get_or_insert` returns `RefEntry` (which requires a guard to release), while `SkipMap.get_or_insert` returns `Entry` (which does not require a guard for release, as implied by the lack of guard parameter in `Entry.remove()` in SkipMap). This inconsistency forces users to handle lifetimes and guards differently for seemingly identical logical operations depending on whether they use the base `SkipList` or the typed `SkipMap`.
- Inconsistent verb usage for state management operations. `register`/`unregister` and `watch`/`unwatch` are used for managing operations, but `try_select` and `accept` are used for execution/consumption. The distinction between `register` and `watch` is not immediately obvious from the names alone without deep documentation, as both seem to associate an operation with the handle. Similarly, `accept` consumes a token, but `unregister` removes an operation. The verbs `register`, `watch`, `accept`, `unregister`, `unwatch` create a slightly confusing set of actions for what is essentially a lifecycle of an async operation.
- Inverted test pyramid
- Off the main sequence: crossbeam-utils
- Off-boarding risk: anonymized user #1