# Changelog

## Score

- CAI 56 → 56 (-0.3)

## Lenses

- Code Health 100 → 100 (+0.0)
- Architecture 69 → 69 (+0.0)
- Maturity 55 → 54 (-1.0)
- Readiness 43 → 43 (+0.0)
- Security 91 → 91 (+0.0)

## Resolved (4)

- Three distinct overloads of `register` exist with different factory types (`ResolverFactory`, `ResolverFactoryResolver`, `ResolverFactoryArgumentsN`). It is unclear if these represent distinct dependency injection strategies (e.g., simple init, property injection, argument injection) or if they are redundant aliases for the same underlying mechanism. The naming convention is inconsistent and opaque to the user.
- Two overloads of `resolveProperties` with different factory types. Similar to the `register` issue, this duplication suggests unclear distinction between simple property injection and argument-based property injection.
- Two properties, `application` and `cached`, both resolve to the same type `ResolverScopeCache`. This suggests they are aliases for the same singleton-like behavior, creating confusion about whether they are interchangeable or if one is deprecated/legacy.
- While `optional` is a valid distinct operation, the naming convention `resolve` vs `optional` is inconsistent with common DI patterns which often use `resolve` and `tryResolve` or `get` and `getOptional`. More importantly, `optional` returns `Service?` but `resolve` throws or crashes on failure (implied by non-optional return). This is a minor inconsistency in naming style compared to the `Injected`/`OptionalInjected` pattern, but acceptable. However, the existence of `Resolver.optional` alongside `Resolver.resolve` creates a split in the API surface for the same core intent (fetching a service).