# 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 40 → 40 (+0.2)
- Rubric changed (rubric-2026.08.18 → rubric-2026.08.19) — scores are not directly comparable.

## Lenses

- Code Health 84 → 84 (+0.0)
- Architecture 84 → 84 (+0.0)
- Maturity 53 → 53 (+0.0)
- Readiness 38 → 38 (+0.0)
- Security 31 → 31 (+0.2)
- Accessibility 45 → 45 (+0.4)

## Resolved (11)

- High: security finding (details withheld)
- High: security finding (details withheld)
- High: security finding (details withheld)
- Medium CVE: Azure.Identity 1.6.0
- Medium CVE: Azure.Identity 1.6.0
- The Unit of Work pattern is implemented in two different locations with different naming conventions. One is a concrete class in the Infrastructure layer, while the other is an interface in the Application layer. While this is a common architectural pattern, the naming suggests a potential confusion between the interface and the implementation, or a split in responsibility.
- The concept of an auditable entity is represented by an interface (IAuditableEntity) and a base class (AuditableWithBaseEntity). While this is a valid pattern, the naming does not clearly indicate that one is the contract and the other is the implementation. Additionally, the property names (Author, Modified, Created, etc.) are consistent, but the type names are quite different.
- Two different interfaces, IRepository and IRepositoryService, both appear to provide repository-like functionality (e.g., Get, Add, Update, Delete). The naming suggests one might be a low-level data access interface and the other a higher-level service interface, but the overlap in method names (Get, Add, Update, Delete) creates ambiguity about which interface to use for which purpose.
- misleading comment (Infrastructure/Persistence/ApplicationDBContext.cs)
- misleading comment (WebApp/Program.cs)
- redundant comment (Infrastructure/Persistence/ApplicationDBContext.cs)

## New (15)

- Delete methods are named 'Delete' and 'DeleteAsync' in both interface and implementation, which is consistent. However, 'Delete' takes an entity or expression, while 'DeleteAsync' takes an object or expression. The parameter types differ slightly.
- High: security finding (details withheld)
- High: security finding (details withheld)
- High: security finding (details withheld)
- High: security finding (details withheld)
- Medium CVE: Azure.Identity 1.6.0
- Medium CVE: Azure.Identity 1.6.0
- Retrieval of entities is named inconsistently across interfaces. 'Get' and 'GetAll' are used in IRepository, while 'GetAsync' and 'GetByIdAsync' are used in IRepositoryService. The naming convention for the base repository interface differs from the service interface.
- The Blazor README ends with a clip marker before any roadmap/contribution sections are shown, so completeness cannot be confirmed. (README.md)
- The UnitOfWork class implements transaction methods with 'Transaction' suffix, while the interface IUnitOfWork also has these methods. However, the interface IUnitOfWork also has 'Save' and 'SaveAsync', which are not transactional but persistence operations. The naming is consistent within the UnitOfWork class, but the interface IUnitOfWork mixes transactional and persistence concerns.
- The method 'Get' in EfRepository and IRepository<T> likely performs a single entity lookup by ID or key, but the name 'Get' is ambiguous compared to 'GetById' or 'GetByKey'.
- Update methods exist in both sync and async forms, but the sync 'Update' is present in the interface while the async 'UpdateAsync' is also present. However, 'EfRepository' implements both. The inconsistency is that 'Update' is used for synchronous updates while 'UpdateAsync' is for asynchronous, which is consistent, but the interface exposes both, potentially causing confusion about which to use.
- misleading comment (Infrastructure/Persistence/ApplicationDBContext.cs)
- misleading comment (Infrastructure/Persistence/ApplicationDBContext.cs)
- redundant comment (WebApp/Program.cs)

## Architecture

- Unchanged — 2 containers · 1 contexts · 0 edges