# Changelog

## Score

- CAI 46 → 48 (+2.2)
- Rubric changed (rubric-2026.08.18 → rubric-2026.08.19) — scores are not directly comparable.

## Lenses

- Code Health 67 → 71 (+3.7)
- Architecture 94 → 94 (+0.0)
- Maturity 61 → 66 (+5.0)
- Readiness 43 → 48 (+5.0)
- Security 33 → 33 (+0.0)
- Event-Driven 100 → 100 (+0.0)
- Performance 70 → 70 (+0.0)

## Resolved (20)

- Async multi-handler classes are named with a generic 'MultiHandlerAsync' prefix followed by a number.
- High CVE: MessagePack 2.5.192
- High CVE: MessagePack 2.5.192
- Inconsistent naming for benchmark classes. One uses 'WithPipelineR' and the other does not, but both seem to be benchmarking the same 'MediatR vs DispatchR' comparison, leading to confusion about which benchmark covers which scenario.
- Inconsistent naming for the same request type. The request class is named 'PingMediatR' in some places but 'PingHandlerMediatR' in others, suggesting a confusion between the request DTO and its handler or a redundant naming pattern.
- Inconsistent naming for the same request type. The request class is named 'PingMediatSG' in some places but 'PingHandlerMediatSG' in others.
- Medium CVE: MessagePack 2.5.192
- Medium CVE: MessagePack 2.5.192
- Medium CVE: MessagePack 2.5.192
- Medium CVE: MessagePack 2.5.192
- Medium CVE: MessagePack 2.5.192
- Medium CVE: MessagePack 2.5.192
- Medium CVE: MessagePack 2.5.192
- Medium CVE: MessagePack 2.5.192
- Medium CVE: MessagePack 2.5.192
- Multi-handler classes are named with a generic 'MultiHandler' prefix followed by a number, which does not indicate the specific notification type they handle.
- Off-boarding risk: anonymized user #1
- Pipeline behaviors are named 'First' and 'Second' which implies an order of execution but lacks semantic meaning about what the behavior does (e.g., Logging, Validation).
- Pipeline behaviors in tests are named based on return type (WithResponse/WithoutResponse) and task type (Generic/Task). This is somewhat descriptive but inconsistent with the production code's simpler naming.
- The stream handler for 'CounterStreamRequest' is named 'CounterStreamHandler' in both MediatR and DispatchR namespaces, which is consistent, but the request type is 'CounterStreamRequest' while the handler is 'CounterStreamHandler'. This is consistent, however, the request type in MediatR is 'CounterStreamRequest' but in DispatchR it is also 'CounterStreamRequest'. The inconsistency is that MediatR uses 'CounterStreamHandler' while DispatchR also uses 'CounterStreamHandler'. Wait, this is consistent. Let's look for actual inconsistencies.

## New (17)

- High CVE: MessagePack 2.5.192
- High CVE: MessagePack 2.5.192
- Inconsistent casing in suffix 'MediatR' vs 'MediatSg'. 'MediatR' is used in one place, while 'MediatSg' (likely a typo or inconsistent abbreviation) is used in another.
- Inconsistent casing in suffix 'MediatR' vs 'MediatSg'. 'MediatR' is used in one place, while 'MediatSg' is used in another.
- Inconsistent suffix for MediatR vs DispatchR implementations. 'MediatR' is used for some types, while 'MediatSG' (likely a typo or inconsistent abbreviation for MediatR) is used for others.
- Inconsistent suffix for MediatR vs DispatchR implementations. 'MediatR' is used for some types, while 'MediatSG' is used for others.
- Medium CVE: MessagePack 2.5.192
- Medium CVE: MessagePack 2.5.192
- Medium CVE: MessagePack 2.5.192
- Medium CVE: MessagePack 2.5.192
- Medium CVE: MessagePack 2.5.192
- Medium CVE: MessagePack 2.5.192
- Medium CVE: MessagePack 2.5.192
- Medium CVE: MessagePack 2.5.192
- Medium CVE: MessagePack 2.5.192
- Off-boarding risk: anonymized user #1
- redundant comment (src/DispatchR/Configuration/ServiceRegistrator.cs)

## API surface

- Unchanged — 10 HTTP endpoints