# Changelog

## Score

- CAI 36 → 36 (+0.3)

## Lenses

- Code Health 61 → 62 (+0.1)
- Architecture 84 → 96 (+12.2)
- Maturity 43 → 43 (+0.0)
- Readiness 18 → 18 (+0.0)
- Security 62 → 62 (+0.0)
- Event-Driven 100 → 100 (+0.0)
- Performance 45 → 45 (+0.0)

## Resolved (13)

- Change coupling: IChannelAccessor.cs ↔ RabbitMqMessageConsumer.cs (src/LinFx.Extensions.RabbitMQ/IChannelAccessor.cs)
- Change coupling: IConnectionPool.cs ↔ RabbitMqMessageConsumerFactory.cs (src/LinFx.Extensions.RabbitMQ/IConnectionPool.cs)
- High CVE: System.Text.Json 8.0.3
- High CVE: System.Text.Json 8.0.3
- Inconsistent delete signatures. `TenantController` uses a simple `id` string, while `FeatureController` uses composite keys `providerName` and `providerKey`. This creates a confusing API surface where delete operations require different numbers of parameters depending on the resource type, despite both being deletion operations.
- Inconsistent return types for identical lookup operations. Both controllers expose a method to retrieve a list of items (permissions/features) based on provider identity, but they return different result wrappers: `PermissionListResultDto` vs `GetFeatureListResultDto`. This forces consumers to handle different response structures for conceptually identical operations.
- Inconsistent return types for update operations. `PermissionController.UpdateAsync` returns `Task` (void), while `FeatureController.UpdateAsync` also returns `Task` (void). While both are void, the lack of a standardized success response (e.g., returning the updated DTO) makes it impossible to confirm the state or retrieve the updated entity, creating a pattern inconsistency with the `TenantController` which returns the updated DTO in Create/Update operations.
- LLM evaluation failed
- ObsoleteWithCallers (src/LinFx.Extensions.EntityFrameworkCore/ObjectExtending/ObjectExtensionPropertyInfoEfMappingOptions.cs)
- ObsoleteWithCallers (src/LinFx.Extensions.MongoDB/Domain/Repositories/MongoDB/MongoDbRepository.cs)
- ObsoleteWithCallers (src/LinFx/Domain/Repositories/IReadOnlyRepository.cs)
- ObsoleteWithCallers (src/LinFx/Domain/Repositories/RepositoryBase.cs)
- The main entry lists 'Polly', 'FluentValidation', 'Metrics' as supported extensions under LinFx.Extensions but does not state which of those are actually present or the full list is visible in the document body. (README.md)

## New (10)

- Change coupling: AuthorizationPolicyProvider.cs ↔ AuthorizationService.cs (src/LinFx/Extensions/Authorization/AuthorizationPolicyProvider.cs)
- Change coupling: ChannelPool.cs ↔ RabbitMqConnections.cs (src/LinFx.Extensions.RabbitMQ/ChannelPool.cs)
- High CVE: System.Text.Json 8.0.3
- High CVE: System.Text.Json 8.0.3
- Inconsistent naming for batch operations. Some methods use 'Many' (e.g., SetMany, RemoveMany) while others might use 'Batch' or 'Bulk'. Also, check if 'SetMany' and 'RemoveMany' are consistently named across all cache implementations.
- Inconsistent naming for feature management services. One is named 'FeatureService' while another is 'FeatureManagementProvider' or 'FeatureManagementStore'.
- Inconsistent naming for removing event handlers. One method removes a specific handler, while the other removes all handlers. The naming does not clearly distinguish between 'removing a specific handler' and 'removing all handlers'.
- Return type inconsistency for identical query parameters. Both controllers expose a GetAsync method that takes providerName and providerKey, but PermissionController returns a specific DTO (PermissionListResultDto) while FeatureController returns a different specific DTO (GetFeatureListResultDto). While the parameters are consistent, the lack of a shared interface or base DTO for these 'by-provider' lookups creates a fragmented client experience.
- Return type inconsistency. Both methods perform an update on a provider-keyed resource but return different types (PermissionController returns Task, FeatureController returns Task). While both are async, the lack of a consistent return type (e.g., both returning a generic success wrapper or void) is a minor inconsistency.
- redundant comment (src/LinFx.Extensions.MongoDB/DistributedEvents/IncomingEventRecord.cs)

## API surface

- Unchanged — 11 HTTP endpoints

## Architecture

- Unchanged — 6 containers · 5 contexts · 4 edges