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

## Lenses

- Code Health 69 → 69 (+0.0)
- Architecture 77 → 77 (+0.0)
- Maturity 40 → 40 (+0.0)
- Readiness 44 → 44 (+0.0)
- Security 48 → 53 (+4.9)

## Resolved (7)

- High: security finding (details withheld)
- High: security finding (details withheld)
- Inconsistent controller naming convention: one controller is named 'ActivitiesController' (domain-driven, singular), while another is named 'ValuesController' (generic/placeholder). This suggests 'ValuesController' is a leftover from a template and should be renamed to match the domain-specific naming of 'ActivitiesController'.
- Inconsistent naming convention for Entity Framework migrations: one migration is named with an underscore 'Add_ActivityEntity' while another is named using PascalCase 'AddDescriptionToActivityEntity'. The convention should be consistent (preferably PascalCase for readability).
- Inconsistent naming for CQRS components: 'Details' uses a 'Query' type, while 'List' also uses a 'Query' type. However, 'Create', 'Edit', and 'Delete' use 'Command' types. While 'Query' and 'Command' are technically different in CQRS, the naming of the namespace/structure for 'Details' and 'List' as 'Query' vs 'Command' for mutations is consistent, BUT the 'Details' and 'List' operations are both read operations. It is inconsistent to name the read operation DTO/Request 'Query' for some reads and potentially use different naming for others if they existed. More critically, 'Details' and 'List' are both read operations, yet 'Details' is in a namespace 'Application.Activities.Details' while 'List' is in 'Application.Activities.List'. This is acceptable. However, looking at the types: `Application.Activities.Details.Query` and `Application.Activities.List.Query` are both read operations. `Application.Activities.Create.Command` etc are write operations. The inconsistency is subtle: 'Details' and 'List' are both queries, but 'Details' is a single item and 'List' is a collection. The naming is actually consistent with CQRS. Let's look for a clearer inconsistency. Ah, `Application.Activities.Details` is a namespace, but `Application.Activities.Edit` is also a namespace. `Application.Activities.Create` is a namespace. `Application.Activities.Delete` is a namespace. `Application.Activities.List` is a namespace. `Application.Activities.Edit.Command` is a type. This is consistent. Let's look at `API.Controllers.ActivitiesController` vs `DatingApp.API.Controllers.ValuesController`. This is the main one. Also, `Persistence.Migrations.Add_ActivityEntity` vs `Persistence.Migrations.AddDescriptionToActivityEntity`. The first uses an underscore, the second uses PascalCase. This is an inconsistency in migration naming conventions.
- redundant comment (src/API/Controllers/ValuesController.cs)
- redundant comment (src/API/Controllers/ValuesController.cs)

## New (4)

- High: security finding (details withheld)
- High: security finding (details withheld)
- redundant comment (src/API/Controllers/ValuesController.cs)
- redundant comment (src/API/Controllers/ValuesController.cs)

## API surface

- Unchanged — 10 HTTP endpoints

## Architecture

- Unchanged — 2 containers · 0 contexts · 0 edges