# Changelog

## Score

- CAI 64 → 59 (-4.8)
- Rubric changed (rubric-2026.10.1 → rubric-2026.10.5) — scores are not directly comparable.

## Lenses

- Code Health 97 → 74 (-22.9)
- Architecture 100 → 100 (+0.0)
- Maturity 45 → 41 (-3.1)
- Readiness 63 → 63 (+0.0)
- Security 97 → 97 (+0.0)

## Resolved (6)

- Inconsistent method signatures and naming for search operations. `binary_search` takes a container and an item. `kmp_search` takes a string and a substring, but also has an overload `kmp_search(substring)` which is ambiguous (searches what?). The naming `kmp_search` is algorithm-specific rather than intent-specific (e.g., `find_substring`).
- Inconsistent naming for existence checks. Most keyed containers use `has_key?`, but `PriorityQueue` uses `has_priority?`. This breaks the pattern of checking for the primary identifier. If the primary identifier is the priority, it should likely be `has_key?` or the API should consistently use `has_priority?` across all priority-based structures (though Heap doesn't expose this method).
- Inconsistent naming for extremum retrieval. `Heap` uses `next_key()` (which is ambiguous with `next()`), while `RBTreeMap` uses `min_key()`/`max_key()`. `SplayTreeMap` uses `min()`/`max()`. `MaxHeap`/`MinHeap` use `max()`/`min()`. The presence of `_key` suffix in some but not others is inconsistent. Additionally, `Heap.next_key()` is confusingly named compared to `min_key()`.
- Inconsistent naming for insertion operations. Map-like structures (RBTree, SplayTree, Trie) and Heap use `push` for inserting key-value pairs. However, `PriorityQueue` uses `push` for object-priority pairs, while `Queue` and `Stack` use `push` for single objects. While `push` is common in Ruby for arrays, for associative containers, `put`, `set`, or `insert` is often clearer. The main inconsistency is between `push` (key, value) in Maps/Heaps vs `push` (obj) in Queues/Stacks, which masks the structural difference (keyed vs unkeyed).
- Inconsistent naming for peek/lookahead operations. Queue, Stack, PriorityQueue, and Heap all use `next()` to retrieve the next element without removing it. However, Ruby's standard library and general convention often use `peek` or `first` for this. More critically, `Containers.Queue` and `Containers.Stack` use `next()` while `Containers.RubyDeque` uses `front()` and `back()`. This creates confusion about whether `next` implies iteration or just inspection.
- Workflow token permissions not restricted

## New (15)

- Inconsistent method signatures for search operations. `binary_search` takes a container and an item, while `kmp_search` has two overloads: one taking a string and substring, and another taking only a substring (implying it operates on an internal state or default string, which is not visible in the signature). This inconsistency in parameter requirements makes the API unpredictable.
- Inconsistent naming for existence checks and lookups. RBTree, SplayTree, and Trie use `get(key)` for retrieval and `has_key?(key)` for existence. Heap uses `has_key?` but also has `next()` for peeking. PriorityQueue uses `has_priority?`. There is no consistent `contains(key)` or `exists(key)` method. Additionally, `get` implies retrieval, while `has_key?` implies boolean check, which is consistent, but the lack of a unified `contains` or `has` method across all types (e.g., Deque doesn't have `has_item?`) is an inconsistency.
- Inconsistent naming for insertion operations. Most associative containers (RBTree, SplayTree, Trie, Heap) and simple containers (Queue, Stack) use `push`. However, PriorityQueue uses `push` but with a different signature (object, priority) compared to Heap (key, value), and Deque uses `push_front`/`push_back` instead of a generic `push`. This forces the user to remember specific method names based on the container type rather than a unified interface.
- Inconsistent naming for peek vs. remove operations. Queue, Stack, PriorityQueue, and Heap all expose both `next()` (peek) and `pop()` (remove). However, RubyRBTreeMap and RubySplayTreeMap use `get(key)` for lookup and `delete(key)` for removal, lacking a consistent 'peek' method for the head/min element. Furthermore, `next()` is a non-standard name for 'peek' in this context, while `pop` is standard for removal. The mix of `next`/`pop` and `get`/`delete` creates confusion about whether an operation is destructive.
- Orphaned file (lib/algorithms/search.rb)
- Orphaned file (lib/algorithms/sort.rb)
- Orphaned file (lib/containers/deque.rb)
- Orphaned file (lib/containers/heap.rb)
- Orphaned file (lib/containers/kd_tree.rb)
- Orphaned file (lib/containers/priority_queue.rb)
- Orphaned file (lib/containers/rb_tree_map.rb)
- Orphaned file (lib/containers/splay_tree_map.rb)
- Orphaned file (lib/containers/suffix_array.rb)
- Orphaned file (lib/containers/trie.rb)
- Workflow token permissions not restricted (.github/workflows/ci.yml)