# 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 43 → 44 (+1.6)
- Rubric changed (rubric-2026.08.17 → rubric-2026.08.18) — scores are not directly comparable.

## Lenses

- Code Health 75 → 79 (+4.2)
- Architecture 87 → 87 (+0.0)
- Maturity 46 → 53 (+6.6)
- Readiness 32 → 32 (+0.0)
- Security 53 → 53 (+0.0)
- Accessibility 49 → 50 (+0.7)

## Resolved (7)

- Duplicated block (7–8 lines × 2) (CleanBlazorWeb/CleanBlazorWeb/Components/Account/Pages/ResendEmailConfirmation.razor)
- High: security finding (details withheld)
- High: security finding (details withheld)
- The IRepository<T> interface defines two methods for deletion: one taking an object (ID) and one taking an expression. While overloading is acceptable, the naming 'Delete' for both is ambiguous. It is unclear if the object parameter represents an ID or a full entity, and if the expression-based method is a soft-delete or hard-delete compared to the other.
- The IUnitOfWork interface has synchronous and asynchronous methods named 'Save' and 'SaveAsync'. However, looking at the implementation 'Infrastructure.Persistence.UnitOfWork', it also has 'Save' and 'SaveAsync'. This is consistent, BUT the interface name 'IUnitOfWork' suggests a Unit of Work pattern which typically commits a transaction. The naming 'Save' is generic. More importantly, there is a method 'CommitTransaction' in the implementation but not in the interface, while 'Save' exists in both. This creates a discrepancy between interface and implementation regarding transaction management methods.
- The interface has 'Update' and 'UpdateAsync'. The parameters differ significantly: 'Update' takes a single entity T, while 'UpdateAsync' takes an object and a T. This inconsistency in parameters for the same conceptual operation (updating) is confusing.
- The method 'Get' is used in both the interface and the concrete class. However, 'Get' is a very generic name. In the same repository, there is 'GetMany' and 'Count'. The use of 'Get' for a filtered query is ambiguous compared to 'GetById' or 'GetByCondition'.

## New (5)

- Duplicated block (7 lines × 2) (CleanBlazorWeb/CleanBlazorWeb/Components/Account/Pages/ResendEmailConfirmation.razor)
- High: security finding (details withheld)
- High: security finding (details withheld)
- The interface IRepository defines two Delete methods with different parameter types: one taking an 'object' and another taking the generic type 'T'. This creates ambiguity and potential confusion about which overload to use or what the contract is.
- The interface IUnitOfWork defines a method named 'Save', while the concrete implementation UnitOfWork also has a 'Save' method. However, looking at the list, we see 'Save' and 'SaveAsync' in the interface but the implementation might differ. More critically, we see 'Save' in IUnitOfWork but 'SaveAsync' in EfRepository. While not a direct name clash, the synchronous/asynchronous naming is inconsistent across the Unit of Work and Repository patterns in this codebase (some use Sync, some Async, some neither).

## API surface

- Unchanged — 4 HTTP endpoints

## Architecture

- Unchanged — 3 containers · 1 contexts · 0 edges