# Changelog

## Score

- CAI 66 → 66 (-0.6)
- Rubric changed (rubric-2026.10.1 → rubric-2026.10.5) — scores are not directly comparable.

## Lenses

- Code Health 95 → 96 (+0.8)
- Architecture 87 → 87 (+0.0)
- Maturity 64 → 62 (-2.5)
- Readiness 55 → 55 (+0.0)
- Security 86 → 86 (+0.0)

## Resolved (1)

- Off-boarding risk: anonymized user #1

## New (10)

- Documentation: no project overview (README.md)
- Duplicate intent with inconsistent signatures. One method is an instance method on a specific data type (Interval) returning a list of that type, while the other is a standalone function accepting raw lists and returning raw lists. This forces the user to choose between using the class or the function for the same logical operation.
- Inconsistent handling of None inputs. `rotate_v3` explicitly handles `None` inputs and returns `None`, while `v1` and `v2` do not show this signature (implying they might crash or are not intended for None). This creates an inconsistent API surface where the same operation has different null-safety guarantees depending on the version chosen.
- Inconsistent key type constraints. `HashTable` restricts keys to `int`, while `SeparateChainingHashTable` allows `object`. This creates confusion about which hash table implementation to use for generic keys, as the base name `HashTable` implies general usage but is restricted.
- Inconsistent naming for deletion. While `del_` is used to avoid Python keyword conflicts, it is inconsistent with standard library conventions (e.g., `dict.pop` or `list.remove`). More importantly, the inconsistency lies in the fact that `del_` is used here, but other structures like `Union` use `unite` or `remove_key` in BTree. However, the primary issue is the inconsistency with `remove_duplicates` which uses a full name. A more critical inconsistency is between `del_` in HashTables and `remove_key` in BTree for the same conceptual operation.
- Off-boarding risk: anonymized user #1
- Orphaned file (algorithms/data_structures/red_black_tree.py)
- Orphaned file (algorithms/data_structures/veb_tree.py)
- While `peek` is consistent between Queue and Stack, it is inconsistent with `PriorityQueue.pop` which retrieves the highest priority item but removes it, and `Heap.remove_min` which also removes. More critically, `PriorityQueue` does not expose a `peek` method in the signature list, whereas `Queue` and `Stack` do. This is an inconsistency in feature parity across similar LIFO/FIFO structures.
- Workflow token permissions not restricted (.github/workflows/publish.yml)