# Changelog

## Score

- CAI 64 → 62 (-2.4)
- 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 54 → 51 (-2.3)
- Readiness 65 → 65 (+0.0)
- Security 100 → 100 (+0.0)
- Performance 85 → 85 (+0.0)

## Resolved (4)

- Ambiguous distinction between checking existence and retrieving value. 'value_loaded?' suggests a boolean check (predicate), while 'loaded_value' suggests retrieval. However, in many batch loading contexts, these are often combined or one implies the other. If 'loaded_value' raises if not loaded, and 'value_loaded?' returns a boolean, they are distinct. But if 'loaded_value' returns nil or a default when not loaded, it duplicates the intent of checking if a value is available. The naming convention (snake_case vs predicate) is also inconsistent with typical Ruby idioms where predicates end in '?' and getters do not.
- Duplicate entry point for creating a batch loader context. Both the main BatchLoader type and the GraphQL-specific GraphQL type expose a static/class method named 'for' that appears to serve the same purpose (creating a loader instance for an item). This creates confusion about which entry point to use.
- Inconsistent naming for synchronization operations. BatchLoader uses a double-underscore prefix (__sync) which is typically reserved for internal/private methods in Ruby, while GraphQL uses a standard public method name (sync). If both are public APIs, the naming convention is inconsistent.
- Workflow token permissions not restricted

## New (5)

- Confusing overlap between loading and querying state. `add` likely registers an item for loading, while `load` sets the result. However, `loaded_value` and `value_loaded?` are distinct methods that likely interact with the same internal state. The distinction between 'adding' an item to the batch and 'loading' its value is not immediately clear from the names alone, and `loaded_value` vs `value_loaded?` suggests a getter vs predicate pattern that could be simplified.
- Duplicate entry points for creating a batch loader instance. `GraphQL.for` and `GraphQL.initialize` appear to serve the same purpose of instantiating a loader, while `BatchLoader.for` is the primary public API. Having multiple ways to create the same object type within the same namespace is confusing.
- Inconsistent naming for synchronization operations. `BatchLoader` uses a double-underscore prefix (`__sync`) which typically implies private/internal implementation, while `GraphQL` exposes a clean public method (`sync`). If both trigger the same underlying batch execution logic, the naming convention is inconsistent regarding visibility.
- Orphaned file (lib/batch_loader.rb)
- Workflow token permissions not restricted (.github/workflows/tests.yml)