# Changelog

> **This is the PUBLIC form of this artifact. Findings are listed in full, but the details of SECURITY findings — which rule fired, in which file, on which line, and how to fix it — are deliberately withheld, and any secret-scanner results are excluded entirely. Where detail is absent here it was REMOVED FOR PUBLICATION; it is not missing from the analysis. The complete artifact is available from the repository owner.**

## Score

- CAI 39 → 45 (+5.9)

## Lenses

- Code Health 58 → 58 (+0.0)
- Architecture 74 → 74 (+0.0)
- Maturity 42 → 43 (+1.6)
- Readiness 29 → 35 (+6.4)
- Security 41 → 58 (+17.5)
- Performance 82 → 82 (+0.0)

## Resolved (12)

- High: security finding (details withheld)
- High: security finding (details withheld)
- High: security finding (details withheld)
- High: security finding (details withheld)
- High: security finding (details withheld)
- High: security finding (details withheld)
- High: security finding (details withheld)
- High: security finding (details withheld)
- The `DapperEventStore` appears in the list, but there is also `Qitar.Store.Dapper.DapperEventStore` and potentially `Qitar.Store.Dapper.DapperEventStore` (if there are multiple implementations or interfaces). If `DapperEventStore` is a class, ensure there isn't a confusingly similar interface like `IDapperEventStore` or `IEventStore` that differs in naming style.
- The concept of the current tenant is accessed via `CurrentTenantAccessor.CurrentTenant` and `Tenant.Identifier`. While one is a property and one is a property on a different type, the naming `CurrentTenant` vs `Tenant` (when referring to the active context) suggests potential confusion about which object represents the active tenant in the current scope.
- The concept of the currently authenticated user is represented by both the `ICurrentUser` interface and the `CurrentUser` property on `IClaimsAccessor`. It is unclear if these are the same concept or if one is a legacy/alternative implementation.
- The naming convention for date/time ranges is inconsistent: `IDateTimeRange` uses 'DateTime' while `DateTimeRangeService` uses 'Date' and 'Range' separately. Additionally, `IDateTimeRangeService` is used in the list, suggesting a potential mismatch between interface and implementation naming.

## New (11)

- High: security finding (details withheld)
- High: security finding (details withheld)
- High: security finding (details withheld)
- High: security finding (details withheld)
- High: security finding (details withheld)
- High: security finding (details withheld)
- High: security finding (details withheld)
- High: security finding (details withheld)
- The bus abstraction is split between `IBusProvider` (which seems to handle publishing/subscribing) and `IBus` (used in parameters). This creates confusion about whether the bus is a provider or a direct service.
- The concept of the 'current user' is represented by a type `ICurrentUser` and a property `CurrentUser` on `IClaimsAccessor`/`ClaimsAccessor`. This mixes a dedicated interface/type with a property on an accessor, which is inconsistent. The accessor pattern (`IClaimsAccessor`) suggests the user info should be retrieved via that accessor, but `ICurrentUser` exists as a standalone type.
- There is an interface `IDateTimeRangeService` and a concrete implementation `DateTimeRangeService`. However, there is also a type `IDateTimeRange` which seems to represent a range, but the service naming is inconsistent with the type naming (Service vs Range).

## Architecture

- Unchanged — 3 containers · 2 contexts · 1 edges