# Changelog

## Score

- CAI 51 → 51 (+0.0)

## Lenses

- Code Health 50 → 50 (+0.0)
- Architecture 74 → 74 (+0.0)
- Maturity 45 → 45 (+0.0)
- Readiness 56 → 56 (+0.0)
- Security 67 → 67 (+0.0)
- Performance 62 → 62 (+0.0)

## Resolved (6)

- Both 'IEventSubscriber' and 'ITrackChildren' expose a 'Setup' method that takes a string endpoint and a Version. This is a strong candidate for interface merging or a shared base interface, as they perform the same initialization step.
- Duplicate intent: Both 'IStoreEvents' and 'IStoreSnapshots' expose a 'GetSnapshot' method. This is a clear duplication of the 'GetSnapshot' operation across two different interfaces that likely represent the same underlying storage concern.
- Inconsistent naming for repository operations: 'Get' implies a mandatory retrieval (often throwing or returning null), while 'TryGet' implies a safe retrieval. However, 'New' is used for creation, which is distinct. The inconsistency lies in the fact that 'Get' and 'TryGet' are standard patterns, but the presence of 'New' for creation is a deviation from the standard 'Create' or 'Add' pattern seen in other ORMs, though this is a minor semantic difference.
- Inconsistent naming for retrieval methods: 'GetEvents' vs 'GetSnapshot'. While semantically different, the pattern 'Get[Entity]' is not followed for snapshots. It should likely be 'GetSnapshot' (which it is), but the inconsistency is that 'GetEvents' is plural while 'GetSnapshot' is singular, and 'GetSnapshot' is in 'IStoreEvents' while 'GetEvents' is also in 'IStoreEvents'. This is actually consistent.
- LLM evaluation failed
- Naming inconsistency in consumer setup methods: 'SetupProjection' vs 'SetupChildrenProjection'. The prefix 'Setup' is used, but the second method explicitly includes 'Children' in the name rather than using a parameter or a more generic 'SetupProjection' with a 'Children' flag or separate interface.

## New (9)

- Duplicate method name 'Plan' with different parameter types (TestableId vs Id) causing ambiguity.
- Inconsistent naming for repository retrieval operations. Some use 'Get' while others use 'Plan' for similar retrieval/lookup operations on entities.
- Inconsistent naming for retrieval operations. 'Get' implies a mandatory return (or exception on failure), while 'TryGet' implies a safe, non-throwing retrieval. However, both 'Get' and 'TryGet' in the interface return the entity (not a bool/optional), making the semantic difference between 'Get' and 'TryGet' confusing. Additionally, 'Get' and 'TryGet' have identical signatures (plus bucket), suggesting they might be redundant or one should return an optional/nullable type instead of throwing.
- Inconsistent naming for verification/checking operations. Some use 'Check' while others use 'Raised' or 'EventChecker' for similar verification logic.
- Inconsistent setup methods for event consumption. 'IEventSubscriber' uses 'Setup' for general endpoints, while 'IEventStoreConsumer' uses 'SetupProjection' and 'SetupChildrenProjection'. This splits the concept of 'starting to listen' into multiple methods with different signatures and naming conventions.
- Overloaded method 'Plan' exists with different parameter types, which can be confusing.
- Redundant/Confusing service execution patterns. 'ContextExtensions.Service' and 'IProcessor.Process' both handle service execution. 'ContextExtensions' offers overloads for both direct service instances and Action<T> delegates, while 'IProcessor' also offers both. This suggests a duplication of intent: is the context extension the public API or the processor? The naming 'Service' vs 'Process' is inconsistent for the same conceptual operation.
- The child entity repository interface duplicates the 'Get' and 'TryGet' naming convention but omits the 'bucket' parameter found in the parent interface. This creates an inconsistent API surface where the same operation (retrieval) has different parameters depending on the generic signature, which is confusing for consumers.
- The method 'Plan' is overloaded with different parameter types, which can be confusing.

## Architecture

- Unchanged — 1 containers · 1 contexts · 0 edges