# Changelog

## Score

- CAI 68 → 65 (-3.4)
- Rubric changed (rubric-2026.10.1 → rubric-2026.10.5) — scores are not directly comparable.

## Lenses

- Code Health 100 → 76 (-24.3)
- Architecture 93 → 93 (+0.0)
- Maturity 55 → 54 (-1.0)
- Readiness 64 → 64 (+0.0)
- Security 96 → 96 (+0.0)

## Resolved (5)

- Ambiguous predicate vs getter. `with_values?` is likely a predicate checking if values exist, but `with_values` is the getter. However, in the `WithCTE` class, `with_values` is also a setter (`with_values=`). The presence of `with_values?` alongside `with_values` and `with_values=` is acceptable in Ruby (ActiveRecord style), BUT `with_values` is also listed as a method that might behave differently than a simple attribute reader. More critically, `recursive_value` and `recursive_value?` follow the same pattern, but `with_values` is the primary state holder. The inconsistency lies in `Window` having `window_values?` while `WithCTE` has `with_values?`, but `WithCTE` also has `with_values` as a method that might do more than just return an attribute (given the `build_with` method exists).
- Inconsistent accessor pattern. Standard Ruby convention for a setter/getter pair is `values` and `values=`. The presence of `window_values?` suggests a predicate (boolean check), while `window_values` and `window_values!` suggest different modes of retrieval or mutation. This creates ambiguity: does `window_values` return the value or trigger a side effect? Does `window_values!` mutate state? The mix of predicate (`?`) and bang (`!`) on the same attribute name is non-standard and confusing.
- Potential redundancy with `with_values`. The `WithCTE` class has both `cte`/`cte=` and `with_values`/`with_values=`. It is unclear if these refer to the same underlying data structure. If `cte` is just an alias for `with_values`, it creates confusion. If they are different (e.g., `cte` is the raw Arel node, `with_values` is the processed array), the naming should reflect that distinction (e.g., `raw_cte` vs `with_values`).
- Redundant naming convention for state mutation. The `!` suffix in Ruby typically implies mutation or danger, but `unionize_storage` is already a specific internal setup method. Having both a non-mutating and mutating version without clear semantic distinction (e.g., one returning self, one void) is confusing. Furthermore, `unionize_storage!` appears to be the primary implementation, making the non-bang version likely just a wrapper or alias, which violates DRY principles in API design.
- Workflow token permissions not restricted

## New (5)

- Confusing API surface: Exposing `window_values`, `window_values!`, and `window_values?` on the same class is highly unusual and confusing. Typically, `?` is for boolean checks, `!` for mutation, and the base for access. Having all three as distinct methods on the same receiver suggests a lack of clear intent or a copy-paste error in API design.
- Duplicate intent: Network containment logic is exposed via two different entry points with different signatures. One is a query method on the scope (Inet), the other is a predicate method (Predications). This forces users to choose between chaining styles inconsistently.
- Redundant accessors: `with_values` and `with_values?` likely return the same data or a boolean check on the same data. Having both as public methods on the main class creates confusion about which one to use.
- Redundant naming: The distinction between `unionize_storage` and `unionize_storage!` is unclear. In Ruby conventions, `!` often implies mutation or danger, but here it likely just returns a different object type or forces evaluation. Without clear documentation, this looks like accidental duplication or inconsistent naming convention compared to other methods like `union` vs `union!`.
- Workflow token permissions not restricted (.github/workflows/test.yml)