Executive summary
NimblePros/eShopOnWeb scores 45 out of 100 and is rated Adequate, while seven of its eight lenses score higher still: Performance at 100 and Architecture at 86, both rated Exemplary, Code Health at 70, rated Strong, and Security and Compliance at 66, Domain Modelling at 54, Production Readiness at 52 and Maturity at 49, all rated Adequate. Watchdog judged it as a template, sample or demo, meant to be read or copied, so the dimensions about building, releasing and running a product don't apply, and its lenses are rated against a lower bar. The score itself is worked out as for any repository.
The score is lower than those seven because the weakest lens counts most, and here that is Accessibility, which scores 33 and is rated Weak. Its Text alternatives dimension scores 1.2 out of 10, and until that reaches 4, Accessibility can't be rated higher than Adequate. The first actions are to add a text alternative — alt on images (alt="" for purely decorative ones), a title or aria-label on meaningful svg, an aria-label or inner fallback content on canvas, and a captions <track> on video and to make custom controls keyboard-operable (role + tabindex + key handler), drop positive tabindex, and give anchors a real href, and if Accessibility rose to 70, the score would rise from 45 to about 54.
82 findings are critical: 20 in Text alternatives, 13 in Forms & labels, 12 in Static Analysis (SAST), seven in REDACTED Scanning, six in Explicit Debt, five in Secrets (history), four in Aggregate boundaries, four in Dependency Vulnerabilities, four in Project dependency cycles, three in Page structure, two in IaC & Container Security and two in Keyboard semantics.
Watchdog couldn't measure 4 dimensions in this code, among them Test Reliability, Dependency Hygiene and Malicious Dependencies, so they are left out of the score. The product code is 7,033 lines, which would take an estimated 0.1 person-years, around €13,000, to rebuild.
If Accessibility rose from 33 to 70, the lowest score rated Strong, the score would rise from 45 to about 54.
New since the last survey: 67 findings
- REDACTED Scanning · REDACTED
- REDACTED Scanning · REDACTED
- REDACTED Scanning · REDACTED
- REDACTED Scanning · REDACTED
- REDACTED Scanning · REDACTED
- REDACTED Scanning · REDACTED
- Secrets (history) · REDACTED
- Secrets (history) · REDACTED
- Secrets (history) · REDACTED
- Secrets (history) · REDACTED
- Static Analysis (SAST) · REDACTED
- Static Analysis (SAST) · REDACTED
- Static Analysis (SAST) · REDACTED
- Static Analysis (SAST) · REDACTED
- Static Analysis (SAST) · REDACTED
- Static Analysis (SAST) · REDACTED
- Static Analysis (SAST) · REDACTED
- Static Analysis (SAST) · REDACTED
- Dependency Vulnerabilities · REDACTED
- Dependency Vulnerabilities · REDACTED
- Dependency Vulnerabilities · REDACTED
- IaC & Container Security · REDACTED
- IaC & Container Security · REDACTED
- IaC & Container Security · REDACTED
- Supply-chain Provenance & Signing · REDACTED
- Supply-chain Provenance & Signing · REDACTED
- Supply-chain Provenance & Signing · REDACTED
- Documentation (README) · README may be stale
- Cancellation propagation · Async method without CancellationToken: AddItemToBasket src/ApplicationCore/Services/BasketService.cs
- Cancellation propagation · Async method without CancellationToken: DeleteBasketAsync src/ApplicationCore/Services/BasketService.cs
- Cancellation propagation · Async method without CancellationToken: SetQuantities src/ApplicationCore/Services/BasketService.cs
- Cancellation propagation · Async method without CancellationToken: TransferBasketAsync src/ApplicationCore/Services/BasketService.cs
- Cancellation propagation · Async method without CancellationToken: CreateOrderAsync src/ApplicationCore/Services/OrderService.cs
- Cancellation propagation · Async local function without CancellationToken: ClearLocalStorageCache src/BlazorAdmin/Program.cs
- Cancellation propagation · Async method without CancellationToken: ListPaged src/BlazorAdmin/Services/CachedCatalogItemServiceDecorator.cs
- Cancellation propagation · Async method without CancellationToken: List src/BlazorAdmin/Services/CachedCatalogItemServiceDecorator.cs
- Cancellation propagation · Async method without CancellationToken: GetById src/BlazorAdmin/Services/CachedCatalogItemServiceDecorator.cs
- Cancellation propagation · Async method without CancellationToken: Create src/BlazorAdmin/Services/CachedCatalogItemServiceDecorator.cs
- Cancellation propagation · Async method without CancellationToken: Edit src/BlazorAdmin/Services/CachedCatalogItemServiceDecorator.cs
- Cancellation propagation · Async method without CancellationToken: Delete src/BlazorAdmin/Services/CachedCatalogItemServiceDecorator.cs
- Cancellation propagation · Async method without CancellationToken: List src/BlazorAdmin/Services/CachedCatalogLookupDataServiceDecorator .cs
- Cancellation propagation · Async method without CancellationToken: Create src/BlazorAdmin/Services/CatalogItemService.cs
- Cancellation propagation · Async method without CancellationToken: Edit src/BlazorAdmin/Services/CatalogItemService.cs
- Cancellation propagation · Async method without CancellationToken: Delete src/BlazorAdmin/Services/CatalogItemService.cs
- Cancellation propagation · Async method without CancellationToken: GetById src/BlazorAdmin/Services/CatalogItemService.cs
- Cancellation propagation · Async method without CancellationToken: ListPaged src/BlazorAdmin/Services/CatalogItemService.cs
- Cancellation propagation · Async method without CancellationToken: List src/BlazorAdmin/Services/CatalogItemService.cs
- Cancellation propagation · Async method without CancellationToken: List src/BlazorAdmin/Services/CatalogLookupDataService.cs
- Cancellation propagation · Async method without CancellationToken: List src/BlazorAdmin/Services/RoleManagementService.cs
- Cancellation propagation · Async method without CancellationToken: Create src/BlazorAdmin/Services/RoleManagementService.cs
- Incompleteness & stubs · Hollow method — returns a constant without doing the work src/Infrastructure/Services/LoggerEmailSender.cs
- Outbound HTTP resilience · Outbound HTTP without resilience src/BlazorAdmin/Program.cs
- Outbound HTTP resilience · Outbound HTTP without resilience src/Web/Extensions/ServiceCollectionExtensions.cs
- Outbound HTTP resilience · Outbound HTTP without resilience src/Web/HealthChecks/HomePageHealthCheck.cs
- Keyboard semantics · Modal dialog does not manage focus src/BlazorAdmin/Pages/CatalogItemPage/Create.razor
- Keyboard semantics · Modal dialog does not manage focus src/BlazorAdmin/Pages/CatalogItemPage/Delete.razor
- Keyboard semantics · Modal dialog does not manage focus src/BlazorAdmin/Pages/CatalogItemPage/Details.razor
- Keyboard semantics · Modal dialog does not manage focus src/BlazorAdmin/Pages/CatalogItemPage/Edit.razor
- Keyboard semantics · Modal dialog does not manage focus src/BlazorAdmin/Pages/RolePage/Create.razor
- Keyboard semantics · Modal dialog does not manage focus src/BlazorAdmin/Pages/RolePage/Delete.razor
- Keyboard semantics · Modal dialog does not manage focus src/BlazorAdmin/Pages/RolePage/DeleteUserFromRole.razor
- Keyboard semantics · Modal dialog does not manage focus src/BlazorAdmin/Pages/RolePage/Edit.razor
- Keyboard semantics · Modal dialog does not manage focus src/BlazorAdmin/Pages/UserPage/Create.razor
- Keyboard semantics · Modal dialog does not manage focus src/BlazorAdmin/Pages/UserPage/Delete.razor
- Keyboard semantics · Modal dialog does not manage focus src/BlazorAdmin/Pages/UserPage/Edit.razor
- Visual & motion safety · Animation without a prefers-reduced-motion guard src/Web/wwwroot/css/shared/components/identity/identity.css
- Visual & motion safety · Animation without a prefers-reduced-motion guard src/Web/wwwroot/css/shared/components/identity/identity.css
Fixed since the last survey: 6 findings
- Coupling · Off the main sequence: eShopWeb.AspireServiceDefaults
- Explicit Debt · TodoComment REDACTED
- Explicit Debt · TodoComment REDACTED
- Supply-chain Provenance & Signing REDACTED
- Web-Security Posture · Token validation disabled src/PublicApi/Extensions/ServiceCollectionExtensions.cs
- Page structure · Routed page without a <PageTitle> src/Web/Pages/Basket/Index.cshtml
Rebuild cost: about €13,000 · Estimate
| Cost to rebuild | €4,500 to €22,000, for 75 to 235 hours of work, about 0.1 person-years for one engineer |
|---|---|
| Difficulty of the problem | High, judged from the kind of software and how it is built. Code that solves a harder problem, such as payments or medical bookings, costs more per line to write. |
| Quality factor | ×0.7 at a score of 45. Better code takes more work to write, so the factor is ×1.0 at a score of 70, lower below it and higher above it. |
| Size | Small: 7,033 lines of product code |
Top priorities
Diagnosis: what the measurements show together
Architecture — module dependency graph
Architecture: which parts of the code depend on which
| uses → | 1 BlazorAdmin.Models | 2 BlazorShared | 3 Microsoft.eShopWeb.PublicApi | 4 BlazorAdmin.Interfaces | 5 BlazorShared.Models | 6 Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate | 7 Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate | 8 Microsoft.eShopWeb.PublicApi.UserManagementEndpoints.Models | 9 BlazorShared.Interfaces | 10 Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.Events | 11 Microsoft.eShopWeb.ApplicationCore.Interfaces | 12 Microsoft.eShopWeb.Web.ViewModels | 13 BlazorAdmin.Services | 14 Microsoft.eShopWeb.ApplicationCore.Entities | 15 Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.Handlers | 16 Microsoft.eShopWeb.Infrastructure.Identity | 17 Microsoft.eShopWeb.Web.Features.MyOrders | 18 Microsoft.eShopWeb.Web.Features.OrderDetails | 19 BlazorAdmin.Helpers | 20 Microsoft.eShopWeb.ApplicationCore.Entities.BuyerAggregate | 21 Microsoft.eShopWeb.ApplicationCore.Services | 22 Microsoft.eShopWeb.Infrastructure.Data | 23 Microsoft.eShopWeb.Infrastructure.Data.Config | 24 Microsoft.eShopWeb.PublicApi.AuthEndpoints | 25 Microsoft.eShopWeb.PublicApi.CatalogBrandEndpoints | 26 Microsoft.eShopWeb.PublicApi.CatalogItemEndpoints | 27 Microsoft.eShopWeb.PublicApi.CatalogTypeEndpoints | 28 Microsoft.eShopWeb.PublicApi.RoleManagementEndpoints | 29 Microsoft.eShopWeb.PublicApi.RoleMembershipEndpoints | 30 Microsoft.eShopWeb.PublicApi.UserManagementEndpoints | 31 Microsoft.eShopWeb.Web.Areas.Identity.Pages.Account | 32 Microsoft.eShopWeb.Web.Controllers | 33 Microsoft.eShopWeb.Web.Pages.Basket | 34 BlazorAdmin.Pages.CatalogItemPage | 35 BlazorAdmin.Pages.RolePage | 36 BlazorAdmin.Pages.UserPage | 37 Microsoft.eShopWeb.Infrastructure.Data.Queries | 38 Microsoft.eShopWeb.PublicApi.Extensions | 39 Microsoft.eShopWeb.Web.Interfaces | 40 Microsoft.eShopWeb.Web.Services |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 BlazorAdmin.Models | ||||||||||||||||||||||||||||||||||||||||
| 2 BlazorShared | ||||||||||||||||||||||||||||||||||||||||
| 3 Microsoft.eShopWeb.PublicApi | ||||||||||||||||||||||||||||||||||||||||
| 4 BlazorAdmin.Interfaces | 12 | |||||||||||||||||||||||||||||||||||||||
| 5 BlazorShared.Models | 2 | |||||||||||||||||||||||||||||||||||||||
| 6 Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate | 1 | 2 | ||||||||||||||||||||||||||||||||||||||
| 7 Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate | 1 | 2 | ||||||||||||||||||||||||||||||||||||||
| 8 Microsoft.eShopWeb.PublicApi.UserManagementEndpoints.Models | 2 | 1 | ||||||||||||||||||||||||||||||||||||||
| 9 BlazorShared.Interfaces | 2 | |||||||||||||||||||||||||||||||||||||||
| 10 Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.Events | 1 | |||||||||||||||||||||||||||||||||||||||
| 11 Microsoft.eShopWeb.ApplicationCore.Interfaces | 1 | 1 | ||||||||||||||||||||||||||||||||||||||
| 12 Microsoft.eShopWeb.Web.ViewModels | 1 | |||||||||||||||||||||||||||||||||||||||
| 13 BlazorAdmin.Services | 12 | 2 | 2 | 6 | 5 | |||||||||||||||||||||||||||||||||||
| 14 Microsoft.eShopWeb.ApplicationCore.Entities | 3 | |||||||||||||||||||||||||||||||||||||||
| 15 Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.Handlers | 1 | 1 | ||||||||||||||||||||||||||||||||||||||
| 16 Microsoft.eShopWeb.Infrastructure.Identity | 1 | |||||||||||||||||||||||||||||||||||||||
| 17 Microsoft.eShopWeb.Web.Features.MyOrders | 1 | 1 | 1 | |||||||||||||||||||||||||||||||||||||
| 18 Microsoft.eShopWeb.Web.Features.OrderDetails | 1 | 1 | 1 | |||||||||||||||||||||||||||||||||||||
| 19 BlazorAdmin.Helpers | 2 | |||||||||||||||||||||||||||||||||||||||
| 20 Microsoft.eShopWeb.ApplicationCore.Entities.BuyerAggregate | 1 | 2 | ||||||||||||||||||||||||||||||||||||||
| 21 Microsoft.eShopWeb.ApplicationCore.Services | 2 | 2 | 7 | 1 | ||||||||||||||||||||||||||||||||||||
| 22 Microsoft.eShopWeb.Infrastructure.Data | 2 | 2 | 2 | 6 | ||||||||||||||||||||||||||||||||||||
| 23 Microsoft.eShopWeb.Infrastructure.Data.Config | 2 | 2 | 3 | |||||||||||||||||||||||||||||||||||||
| 24 Microsoft.eShopWeb.PublicApi.AuthEndpoints | 2 | 1 | 1 | |||||||||||||||||||||||||||||||||||||
| 25 Microsoft.eShopWeb.PublicApi.CatalogBrandEndpoints | 1 | 1 | 1 | |||||||||||||||||||||||||||||||||||||
| 26 Microsoft.eShopWeb.PublicApi.CatalogItemEndpoints | 9 | 9 | 5 | |||||||||||||||||||||||||||||||||||||
| 27 Microsoft.eShopWeb.PublicApi.CatalogTypeEndpoints | 1 | 1 | 1 | |||||||||||||||||||||||||||||||||||||
| 28 Microsoft.eShopWeb.PublicApi.RoleManagementEndpoints | 8 | 1 | ||||||||||||||||||||||||||||||||||||||
| 29 Microsoft.eShopWeb.PublicApi.RoleMembershipEndpoints | 3 | 3 | ||||||||||||||||||||||||||||||||||||||
| 30 Microsoft.eShopWeb.PublicApi.UserManagementEndpoints | 10 | 3 | 9 | |||||||||||||||||||||||||||||||||||||
| 31 Microsoft.eShopWeb.Web.Areas.Identity.Pages.Account | 1 | 4 | ||||||||||||||||||||||||||||||||||||||
| 32 Microsoft.eShopWeb.Web.Controllers | 3 | 2 | ||||||||||||||||||||||||||||||||||||||
| 33 Microsoft.eShopWeb.Web.Pages.Basket | 5 | 1 | 1 | 1 | 2 | |||||||||||||||||||||||||||||||||||
| 34 BlazorAdmin.Pages.CatalogItemPage | 3 | 2 | 1 | |||||||||||||||||||||||||||||||||||||
| 35 BlazorAdmin.Pages.RolePage | 1 | 1 | ||||||||||||||||||||||||||||||||||||||
| 36 BlazorAdmin.Pages.UserPage | 1 | 1 | 1 | |||||||||||||||||||||||||||||||||||||
| 37 Microsoft.eShopWeb.Infrastructure.Data.Queries | 1 | 1 | ||||||||||||||||||||||||||||||||||||||
| 38 Microsoft.eShopWeb.PublicApi.Extensions | 1 | 1 | 1 | |||||||||||||||||||||||||||||||||||||
| 39 Microsoft.eShopWeb.Web.Interfaces | 1 | 1 | 1 | |||||||||||||||||||||||||||||||||||||
| 40 Microsoft.eShopWeb.Web.Services | 2 | 7 | 4 | 5 | 2 | 2 |
4→1 BlazorAdmin.Interfaces uses BlazorAdmin.Models✕
- Connections
- 12 pairs of types, where a type in BlazorAdmin.Interfaces uses a type in BlazorAdmin.Models.
- The types involved
BlazorAdmin.Interfaces.IRoleManagementService→BlazorAdmin.Models.CreateRoleRequestBlazorAdmin.Interfaces.IRoleManagementService→BlazorAdmin.Models.CreateRoleResponseBlazorAdmin.Interfaces.IRoleManagementService→BlazorAdmin.Models.GetByIdRoleResponseBlazorAdmin.Interfaces.IRoleManagementService→BlazorAdmin.Models.GetRoleMembershipResponseBlazorAdmin.Interfaces.IRoleManagementService→BlazorAdmin.Models.RoleListResponseBlazorAdmin.Interfaces.IUserManagementService→BlazorAdmin.Models.CreateUserRequestBlazorAdmin.Interfaces.IUserManagementService→BlazorAdmin.Models.CreateUserResponseBlazorAdmin.Interfaces.IUserManagementService→BlazorAdmin.Models.GetUserResponseBlazorAdmin.Interfaces.IUserManagementService→BlazorAdmin.Models.GetUserRolesResponseBlazorAdmin.Interfaces.IUserManagementService→BlazorAdmin.Models.SaveRolesForUserRequestBlazorAdmin.Interfaces.IUserManagementService→BlazorAdmin.Models.UpdateUserRequestBlazorAdmin.Interfaces.IUserManagementService→BlazorAdmin.Models.UserListResponse
- Direction
- BlazorAdmin.Interfaces uses BlazorAdmin.Models, so a change to BlazorAdmin.Models can break BlazorAdmin.Interfaces, while a change to BlazorAdmin.Interfaces can't break BlazorAdmin.Models.
- Position
- Below the diagonal: BlazorAdmin.Interfaces uses a module listed above it, which is the healthy direction.
5→9 BlazorShared.Models uses BlazorShared.Interfaces part of a loop✕
- Connections
- 2 pairs of types, where a type in BlazorShared.Models uses a type in BlazorShared.Interfaces.
- The types involved
BlazorShared.Models.CatalogBrandResponse→BlazorShared.Interfaces.ILookupDataResponseBlazorShared.Models.CatalogTypeResponse→BlazorShared.Interfaces.ILookupDataResponse
- Direction
- BlazorShared.Models uses BlazorShared.Interfaces, so a change to BlazorShared.Interfaces can break BlazorShared.Models, while a change to BlazorShared.Models can't break BlazorShared.Interfaces.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
6→11 Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate uses Microsoft.eShopWeb.ApplicationCore.Interfaces part of a loop✕
- Connections
- 1 pair of types, where a type in Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate uses a type in Microsoft.eShopWeb.ApplicationCore.Interfaces.
- The types involved
Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate.Basket→Microsoft.eShopWeb.ApplicationCore.Interfaces.IAggregateRoot
- Direction
- Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate uses Microsoft.eShopWeb.ApplicationCore.Interfaces, so a change to Microsoft.eShopWeb.ApplicationCore.Interfaces can break Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate, while a change to Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate can't break Microsoft.eShopWeb.ApplicationCore.Interfaces.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
6→14 Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate uses Microsoft.eShopWeb.ApplicationCore.Entities part of a loop✕
- Connections
- 2 pairs of types, where a type in Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate uses a type in Microsoft.eShopWeb.ApplicationCore.Entities.
- The types involved
Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate.Basket→Microsoft.eShopWeb.ApplicationCore.Entities.BaseEntityMicrosoft.eShopWeb.ApplicationCore.Entities.BasketAggregate.BasketItem→Microsoft.eShopWeb.ApplicationCore.Entities.BaseEntity
- Direction
- Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate uses Microsoft.eShopWeb.ApplicationCore.Entities, so a change to Microsoft.eShopWeb.ApplicationCore.Entities can break Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate, while a change to Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate can't break Microsoft.eShopWeb.ApplicationCore.Entities.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
7→11 Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate uses Microsoft.eShopWeb.ApplicationCore.Interfaces part of a loop✕
- Connections
- 1 pair of types, where a type in Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate uses a type in Microsoft.eShopWeb.ApplicationCore.Interfaces.
- The types involved
Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.Order→Microsoft.eShopWeb.ApplicationCore.Interfaces.IAggregateRoot
- Direction
- Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate uses Microsoft.eShopWeb.ApplicationCore.Interfaces, so a change to Microsoft.eShopWeb.ApplicationCore.Interfaces can break Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate, while a change to Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate can't break Microsoft.eShopWeb.ApplicationCore.Interfaces.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
7→14 Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate uses Microsoft.eShopWeb.ApplicationCore.Entities part of a loop✕
- Connections
- 2 pairs of types, where a type in Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate uses a type in Microsoft.eShopWeb.ApplicationCore.Entities.
- The types involved
Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.Order→Microsoft.eShopWeb.ApplicationCore.Entities.BaseEntityMicrosoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.OrderItem→Microsoft.eShopWeb.ApplicationCore.Entities.BaseEntity
- Direction
- Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate uses Microsoft.eShopWeb.ApplicationCore.Entities, so a change to Microsoft.eShopWeb.ApplicationCore.Entities can break Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate, while a change to Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate can't break Microsoft.eShopWeb.ApplicationCore.Entities.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
8→3 Microsoft.eShopWeb.PublicApi.UserManagementEndpoints.Models uses Microsoft.eShopWeb.PublicApi✕
- Connections
- 2 pairs of types, where a type in Microsoft.eShopWeb.PublicApi.UserManagementEndpoints.Models uses a type in Microsoft.eShopWeb.PublicApi.
- The types involved
Microsoft.eShopWeb.PublicApi.UserManagementEndpoints.Models.GetUserResponse→Microsoft.eShopWeb.PublicApi.BaseResponseMicrosoft.eShopWeb.PublicApi.UserManagementEndpoints.Models.GetUserRolesResponse→Microsoft.eShopWeb.PublicApi.BaseResponse
- Direction
- Microsoft.eShopWeb.PublicApi.UserManagementEndpoints.Models uses Microsoft.eShopWeb.PublicApi, so a change to Microsoft.eShopWeb.PublicApi can break Microsoft.eShopWeb.PublicApi.UserManagementEndpoints.Models, while a change to Microsoft.eShopWeb.PublicApi.UserManagementEndpoints.Models can't break Microsoft.eShopWeb.PublicApi.
- Position
- Below the diagonal: Microsoft.eShopWeb.PublicApi.UserManagementEndpoints.Models uses a module listed above it, which is the healthy direction.
8→30 Microsoft.eShopWeb.PublicApi.UserManagementEndpoints.Models uses Microsoft.eShopWeb.PublicApi.UserManagementEndpoints part of a loop✕
- Connections
- 1 pair of types, where a type in Microsoft.eShopWeb.PublicApi.UserManagementEndpoints.Models uses a type in Microsoft.eShopWeb.PublicApi.UserManagementEndpoints.
- The types involved
Microsoft.eShopWeb.PublicApi.UserManagementEndpoints.Models.GetUserResponse→Microsoft.eShopWeb.PublicApi.UserManagementEndpoints.UserDto
- Direction
- Microsoft.eShopWeb.PublicApi.UserManagementEndpoints.Models uses Microsoft.eShopWeb.PublicApi.UserManagementEndpoints, so a change to Microsoft.eShopWeb.PublicApi.UserManagementEndpoints can break Microsoft.eShopWeb.PublicApi.UserManagementEndpoints.Models, while a change to Microsoft.eShopWeb.PublicApi.UserManagementEndpoints.Models can't break Microsoft.eShopWeb.PublicApi.UserManagementEndpoints.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
9→5 BlazorShared.Interfaces uses BlazorShared.Models✕
- Connections
- 2 pairs of types, where a type in BlazorShared.Interfaces uses a type in BlazorShared.Models.
- The types involved
BlazorShared.Interfaces.ICatalogItemService→BlazorShared.Models.CatalogItemBlazorShared.Interfaces.ICatalogItemService→BlazorShared.Models.CreateCatalogItemRequest
- Direction
- BlazorShared.Interfaces uses BlazorShared.Models, so a change to BlazorShared.Models can break BlazorShared.Interfaces, while a change to BlazorShared.Interfaces can't break BlazorShared.Models.
- Position
- Below the diagonal: BlazorShared.Interfaces uses a module listed above it, which is the healthy direction.
10→7 Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.Events uses Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate✕
- Connections
- 1 pair of types, where a type in Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.Events uses a type in Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.
- The types involved
Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.Events.OrderCreatedEvent→Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.Order
- Direction
- Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.Events uses Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate, so a change to Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate can break Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.Events, while a change to Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.Events can't break Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.
- Position
- Below the diagonal: Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.Events uses a module listed above it, which is the healthy direction.
11→6 Microsoft.eShopWeb.ApplicationCore.Interfaces uses Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate✕
- Connections
- 1 pair of types, where a type in Microsoft.eShopWeb.ApplicationCore.Interfaces uses a type in Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate.
- The types involved
Microsoft.eShopWeb.ApplicationCore.Interfaces.IBasketService→Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate.Basket
- Direction
- Microsoft.eShopWeb.ApplicationCore.Interfaces uses Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate, so a change to Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate can break Microsoft.eShopWeb.ApplicationCore.Interfaces, while a change to Microsoft.eShopWeb.ApplicationCore.Interfaces can't break Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate.
- Position
- Below the diagonal: Microsoft.eShopWeb.ApplicationCore.Interfaces uses a module listed above it, which is the healthy direction.
11→7 Microsoft.eShopWeb.ApplicationCore.Interfaces uses Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate✕
- Connections
- 1 pair of types, where a type in Microsoft.eShopWeb.ApplicationCore.Interfaces uses a type in Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.
- The types involved
Microsoft.eShopWeb.ApplicationCore.Interfaces.IOrderService→Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.Address
- Direction
- Microsoft.eShopWeb.ApplicationCore.Interfaces uses Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate, so a change to Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate can break Microsoft.eShopWeb.ApplicationCore.Interfaces, while a change to Microsoft.eShopWeb.ApplicationCore.Interfaces can't break Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.
- Position
- Below the diagonal: Microsoft.eShopWeb.ApplicationCore.Interfaces uses a module listed above it, which is the healthy direction.
12→7 Microsoft.eShopWeb.Web.ViewModels uses Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate✕
- Connections
- 1 pair of types, where a type in Microsoft.eShopWeb.Web.ViewModels uses a type in Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.
- The types involved
Microsoft.eShopWeb.Web.ViewModels.OrderViewModel→Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.Address
- Direction
- Microsoft.eShopWeb.Web.ViewModels uses Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate, so a change to Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate can break Microsoft.eShopWeb.Web.ViewModels, while a change to Microsoft.eShopWeb.Web.ViewModels can't break Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.
- Position
- Below the diagonal: Microsoft.eShopWeb.Web.ViewModels uses a module listed above it, which is the healthy direction.
13→1 BlazorAdmin.Services uses BlazorAdmin.Models✕
- Connections
- 12 pairs of types, where a type in BlazorAdmin.Services uses a type in BlazorAdmin.Models.
- The types involved
BlazorAdmin.Services.RoleManagementService→BlazorAdmin.Models.CreateRoleRequestBlazorAdmin.Services.RoleManagementService→BlazorAdmin.Models.CreateRoleResponseBlazorAdmin.Services.RoleManagementService→BlazorAdmin.Models.GetByIdRoleResponseBlazorAdmin.Services.RoleManagementService→BlazorAdmin.Models.GetRoleMembershipResponseBlazorAdmin.Services.RoleManagementService→BlazorAdmin.Models.RoleListResponseBlazorAdmin.Services.UserManagementService→BlazorAdmin.Models.CreateUserRequestBlazorAdmin.Services.UserManagementService→BlazorAdmin.Models.CreateUserResponseBlazorAdmin.Services.UserManagementService→BlazorAdmin.Models.GetUserResponseBlazorAdmin.Services.UserManagementService→BlazorAdmin.Models.GetUserRolesResponseBlazorAdmin.Services.UserManagementService→BlazorAdmin.Models.SaveRolesForUserRequestBlazorAdmin.Services.UserManagementService→BlazorAdmin.Models.UpdateUserRequestBlazorAdmin.Services.UserManagementService→BlazorAdmin.Models.UserListResponse
- Direction
- BlazorAdmin.Services uses BlazorAdmin.Models, so a change to BlazorAdmin.Models can break BlazorAdmin.Services, while a change to BlazorAdmin.Services can't break BlazorAdmin.Models.
- Position
- Below the diagonal: BlazorAdmin.Services uses a module listed above it, which is the healthy direction.
13→2 BlazorAdmin.Services uses BlazorShared✕
- Connections
- 2 pairs of types, where a type in BlazorAdmin.Services uses a type in BlazorShared.
- The types involved
BlazorAdmin.Services.CatalogLookupDataService→BlazorShared.BaseUrlConfigurationBlazorAdmin.Services.HttpService→BlazorShared.BaseUrlConfiguration
- Direction
- BlazorAdmin.Services uses BlazorShared, so a change to BlazorShared can break BlazorAdmin.Services, while a change to BlazorAdmin.Services can't break BlazorShared.
- Position
- Below the diagonal: BlazorAdmin.Services uses a module listed above it, which is the healthy direction.
13→4 BlazorAdmin.Services uses BlazorAdmin.Interfaces✕
- Connections
- 2 pairs of types, where a type in BlazorAdmin.Services uses a type in BlazorAdmin.Interfaces.
- The types involved
BlazorAdmin.Services.RoleManagementService→BlazorAdmin.Interfaces.IRoleManagementServiceBlazorAdmin.Services.UserManagementService→BlazorAdmin.Interfaces.IUserManagementService
- Direction
- BlazorAdmin.Services uses BlazorAdmin.Interfaces, so a change to BlazorAdmin.Interfaces can break BlazorAdmin.Services, while a change to BlazorAdmin.Services can't break BlazorAdmin.Interfaces.
- Position
- Below the diagonal: BlazorAdmin.Services uses a module listed above it, which is the healthy direction.
13→5 BlazorAdmin.Services uses BlazorShared.Models✕
- Connections
- 6 pairs of types, where a type in BlazorAdmin.Services uses a type in BlazorShared.Models.
- The types involved
BlazorAdmin.Services.CachedCatalogItemServiceDecorator→BlazorShared.Models.CatalogItemBlazorAdmin.Services.CachedCatalogItemServiceDecorator→BlazorShared.Models.CreateCatalogItemRequestBlazorAdmin.Services.CatalogItemService→BlazorShared.Models.CatalogBrandBlazorAdmin.Services.CatalogItemService→BlazorShared.Models.CatalogItemBlazorAdmin.Services.CatalogItemService→BlazorShared.Models.CatalogTypeBlazorAdmin.Services.CatalogItemService→BlazorShared.Models.CreateCatalogItemRequest
- Direction
- BlazorAdmin.Services uses BlazorShared.Models, so a change to BlazorShared.Models can break BlazorAdmin.Services, while a change to BlazorAdmin.Services can't break BlazorShared.Models.
- Position
- Below the diagonal: BlazorAdmin.Services uses a module listed above it, which is the healthy direction.
13→9 BlazorAdmin.Services uses BlazorShared.Interfaces✕
- Connections
- 5 pairs of types, where a type in BlazorAdmin.Services uses a type in BlazorShared.Interfaces.
- The types involved
BlazorAdmin.Services.CachedCatalogItemServiceDecorator→BlazorShared.Interfaces.ICatalogItemServiceBlazorAdmin.Services.CachedCatalogLookupDataServiceDecorator→BlazorShared.Interfaces.ICatalogLookupDataServiceBlazorAdmin.Services.CatalogItemService→BlazorShared.Interfaces.ICatalogItemServiceBlazorAdmin.Services.CatalogItemService→BlazorShared.Interfaces.ICatalogLookupDataServiceBlazorAdmin.Services.CatalogLookupDataService→BlazorShared.Interfaces.ICatalogLookupDataService
- Direction
- BlazorAdmin.Services uses BlazorShared.Interfaces, so a change to BlazorShared.Interfaces can break BlazorAdmin.Services, while a change to BlazorAdmin.Services can't break BlazorShared.Interfaces.
- Position
- Below the diagonal: BlazorAdmin.Services uses a module listed above it, which is the healthy direction.
14→11 Microsoft.eShopWeb.ApplicationCore.Entities uses Microsoft.eShopWeb.ApplicationCore.Interfaces✕
- Connections
- 3 pairs of types, where a type in Microsoft.eShopWeb.ApplicationCore.Entities uses a type in Microsoft.eShopWeb.ApplicationCore.Interfaces.
- The types involved
Microsoft.eShopWeb.ApplicationCore.Entities.CatalogBrand→Microsoft.eShopWeb.ApplicationCore.Interfaces.IAggregateRootMicrosoft.eShopWeb.ApplicationCore.Entities.CatalogItem→Microsoft.eShopWeb.ApplicationCore.Interfaces.IAggregateRootMicrosoft.eShopWeb.ApplicationCore.Entities.CatalogType→Microsoft.eShopWeb.ApplicationCore.Interfaces.IAggregateRoot
- Direction
- Microsoft.eShopWeb.ApplicationCore.Entities uses Microsoft.eShopWeb.ApplicationCore.Interfaces, so a change to Microsoft.eShopWeb.ApplicationCore.Interfaces can break Microsoft.eShopWeb.ApplicationCore.Entities, while a change to Microsoft.eShopWeb.ApplicationCore.Entities can't break Microsoft.eShopWeb.ApplicationCore.Interfaces.
- Position
- Below the diagonal: Microsoft.eShopWeb.ApplicationCore.Entities uses a module listed above it, which is the healthy direction.
15→10 Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.Handlers uses Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.Events✕
- Connections
- 1 pair of types, where a type in Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.Handlers uses a type in Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.Events.
- The types involved
Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.Handlers.OrderCreatedHandler→Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.Events.OrderCreatedEvent
- Direction
- Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.Handlers uses Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.Events, so a change to Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.Events can break Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.Handlers, while a change to Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.Handlers can't break Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.Events.
- Position
- Below the diagonal: Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.Handlers uses a module listed above it, which is the healthy direction.
15→11 Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.Handlers uses Microsoft.eShopWeb.ApplicationCore.Interfaces✕
- Connections
- 1 pair of types, where a type in Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.Handlers uses a type in Microsoft.eShopWeb.ApplicationCore.Interfaces.
- The types involved
Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.Handlers.OrderCreatedHandler→Microsoft.eShopWeb.ApplicationCore.Interfaces.IEmailSender
- Direction
- Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.Handlers uses Microsoft.eShopWeb.ApplicationCore.Interfaces, so a change to Microsoft.eShopWeb.ApplicationCore.Interfaces can break Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.Handlers, while a change to Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.Handlers can't break Microsoft.eShopWeb.ApplicationCore.Interfaces.
- Position
- Below the diagonal: Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.Handlers uses a module listed above it, which is the healthy direction.
16→11 Microsoft.eShopWeb.Infrastructure.Identity uses Microsoft.eShopWeb.ApplicationCore.Interfaces✕
- Connections
- 1 pair of types, where a type in Microsoft.eShopWeb.Infrastructure.Identity uses a type in Microsoft.eShopWeb.ApplicationCore.Interfaces.
- The types involved
Microsoft.eShopWeb.Infrastructure.Identity.IdentityTokenClaimService→Microsoft.eShopWeb.ApplicationCore.Interfaces.ITokenClaimsService
- Direction
- Microsoft.eShopWeb.Infrastructure.Identity uses Microsoft.eShopWeb.ApplicationCore.Interfaces, so a change to Microsoft.eShopWeb.ApplicationCore.Interfaces can break Microsoft.eShopWeb.Infrastructure.Identity, while a change to Microsoft.eShopWeb.Infrastructure.Identity can't break Microsoft.eShopWeb.ApplicationCore.Interfaces.
- Position
- Below the diagonal: Microsoft.eShopWeb.Infrastructure.Identity uses a module listed above it, which is the healthy direction.
17→7 Microsoft.eShopWeb.Web.Features.MyOrders uses Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate✕
- Connections
- 1 pair of types, where a type in Microsoft.eShopWeb.Web.Features.MyOrders uses a type in Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.
- The types involved
Microsoft.eShopWeb.Web.Features.MyOrders.GetMyOrdersHandler→Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.Order
- Direction
- Microsoft.eShopWeb.Web.Features.MyOrders uses Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate, so a change to Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate can break Microsoft.eShopWeb.Web.Features.MyOrders, while a change to Microsoft.eShopWeb.Web.Features.MyOrders can't break Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.
- Position
- Below the diagonal: Microsoft.eShopWeb.Web.Features.MyOrders uses a module listed above it, which is the healthy direction.
17→11 Microsoft.eShopWeb.Web.Features.MyOrders uses Microsoft.eShopWeb.ApplicationCore.Interfaces✕
- Connections
- 1 pair of types, where a type in Microsoft.eShopWeb.Web.Features.MyOrders uses a type in Microsoft.eShopWeb.ApplicationCore.Interfaces.
- The types involved
Microsoft.eShopWeb.Web.Features.MyOrders.GetMyOrdersHandler→Microsoft.eShopWeb.ApplicationCore.Interfaces.IReadRepository
- Direction
- Microsoft.eShopWeb.Web.Features.MyOrders uses Microsoft.eShopWeb.ApplicationCore.Interfaces, so a change to Microsoft.eShopWeb.ApplicationCore.Interfaces can break Microsoft.eShopWeb.Web.Features.MyOrders, while a change to Microsoft.eShopWeb.Web.Features.MyOrders can't break Microsoft.eShopWeb.ApplicationCore.Interfaces.
- Position
- Below the diagonal: Microsoft.eShopWeb.Web.Features.MyOrders uses a module listed above it, which is the healthy direction.
17→12 Microsoft.eShopWeb.Web.Features.MyOrders uses Microsoft.eShopWeb.Web.ViewModels✕
- Connections
- 1 pair of types, where a type in Microsoft.eShopWeb.Web.Features.MyOrders uses a type in Microsoft.eShopWeb.Web.ViewModels.
- The types involved
Microsoft.eShopWeb.Web.Features.MyOrders.GetMyOrdersHandler→Microsoft.eShopWeb.Web.ViewModels.OrderViewModel
- Direction
- Microsoft.eShopWeb.Web.Features.MyOrders uses Microsoft.eShopWeb.Web.ViewModels, so a change to Microsoft.eShopWeb.Web.ViewModels can break Microsoft.eShopWeb.Web.Features.MyOrders, while a change to Microsoft.eShopWeb.Web.Features.MyOrders can't break Microsoft.eShopWeb.Web.ViewModels.
- Position
- Below the diagonal: Microsoft.eShopWeb.Web.Features.MyOrders uses a module listed above it, which is the healthy direction.
18→7 Microsoft.eShopWeb.Web.Features.OrderDetails uses Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate✕
- Connections
- 1 pair of types, where a type in Microsoft.eShopWeb.Web.Features.OrderDetails uses a type in Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.
- The types involved
Microsoft.eShopWeb.Web.Features.OrderDetails.GetOrderDetailsHandler→Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.Order
- Direction
- Microsoft.eShopWeb.Web.Features.OrderDetails uses Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate, so a change to Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate can break Microsoft.eShopWeb.Web.Features.OrderDetails, while a change to Microsoft.eShopWeb.Web.Features.OrderDetails can't break Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.
- Position
- Below the diagonal: Microsoft.eShopWeb.Web.Features.OrderDetails uses a module listed above it, which is the healthy direction.
18→11 Microsoft.eShopWeb.Web.Features.OrderDetails uses Microsoft.eShopWeb.ApplicationCore.Interfaces✕
- Connections
- 1 pair of types, where a type in Microsoft.eShopWeb.Web.Features.OrderDetails uses a type in Microsoft.eShopWeb.ApplicationCore.Interfaces.
- The types involved
Microsoft.eShopWeb.Web.Features.OrderDetails.GetOrderDetailsHandler→Microsoft.eShopWeb.ApplicationCore.Interfaces.IReadRepository
- Direction
- Microsoft.eShopWeb.Web.Features.OrderDetails uses Microsoft.eShopWeb.ApplicationCore.Interfaces, so a change to Microsoft.eShopWeb.ApplicationCore.Interfaces can break Microsoft.eShopWeb.Web.Features.OrderDetails, while a change to Microsoft.eShopWeb.Web.Features.OrderDetails can't break Microsoft.eShopWeb.ApplicationCore.Interfaces.
- Position
- Below the diagonal: Microsoft.eShopWeb.Web.Features.OrderDetails uses a module listed above it, which is the healthy direction.
18→12 Microsoft.eShopWeb.Web.Features.OrderDetails uses Microsoft.eShopWeb.Web.ViewModels✕
- Connections
- 1 pair of types, where a type in Microsoft.eShopWeb.Web.Features.OrderDetails uses a type in Microsoft.eShopWeb.Web.ViewModels.
- The types involved
Microsoft.eShopWeb.Web.Features.OrderDetails.GetOrderDetailsHandler→Microsoft.eShopWeb.Web.ViewModels.OrderDetailViewModel
- Direction
- Microsoft.eShopWeb.Web.Features.OrderDetails uses Microsoft.eShopWeb.Web.ViewModels, so a change to Microsoft.eShopWeb.Web.ViewModels can break Microsoft.eShopWeb.Web.Features.OrderDetails, while a change to Microsoft.eShopWeb.Web.Features.OrderDetails can't break Microsoft.eShopWeb.Web.ViewModels.
- Position
- Below the diagonal: Microsoft.eShopWeb.Web.Features.OrderDetails uses a module listed above it, which is the healthy direction.
19→13 BlazorAdmin.Helpers uses BlazorAdmin.Services✕
- Connections
- 2 pairs of types, where a type in BlazorAdmin.Helpers uses a type in BlazorAdmin.Services.
- The types involved
BlazorAdmin.Helpers.ToastComponent→BlazorAdmin.Services.ToastLevelBlazorAdmin.Helpers.ToastComponent→BlazorAdmin.Services.ToastService
- Direction
- BlazorAdmin.Helpers uses BlazorAdmin.Services, so a change to BlazorAdmin.Services can break BlazorAdmin.Helpers, while a change to BlazorAdmin.Helpers can't break BlazorAdmin.Services.
- Position
- Below the diagonal: BlazorAdmin.Helpers uses a module listed above it, which is the healthy direction.
20→11 Microsoft.eShopWeb.ApplicationCore.Entities.BuyerAggregate uses Microsoft.eShopWeb.ApplicationCore.Interfaces✕
- Connections
- 1 pair of types, where a type in Microsoft.eShopWeb.ApplicationCore.Entities.BuyerAggregate uses a type in Microsoft.eShopWeb.ApplicationCore.Interfaces.
- The types involved
Microsoft.eShopWeb.ApplicationCore.Entities.BuyerAggregate.Buyer→Microsoft.eShopWeb.ApplicationCore.Interfaces.IAggregateRoot
- Direction
- Microsoft.eShopWeb.ApplicationCore.Entities.BuyerAggregate uses Microsoft.eShopWeb.ApplicationCore.Interfaces, so a change to Microsoft.eShopWeb.ApplicationCore.Interfaces can break Microsoft.eShopWeb.ApplicationCore.Entities.BuyerAggregate, while a change to Microsoft.eShopWeb.ApplicationCore.Entities.BuyerAggregate can't break Microsoft.eShopWeb.ApplicationCore.Interfaces.
- Position
- Below the diagonal: Microsoft.eShopWeb.ApplicationCore.Entities.BuyerAggregate uses a module listed above it, which is the healthy direction.
20→14 Microsoft.eShopWeb.ApplicationCore.Entities.BuyerAggregate uses Microsoft.eShopWeb.ApplicationCore.Entities✕
- Connections
- 2 pairs of types, where a type in Microsoft.eShopWeb.ApplicationCore.Entities.BuyerAggregate uses a type in Microsoft.eShopWeb.ApplicationCore.Entities.
- The types involved
Microsoft.eShopWeb.ApplicationCore.Entities.BuyerAggregate.Buyer→Microsoft.eShopWeb.ApplicationCore.Entities.BaseEntityMicrosoft.eShopWeb.ApplicationCore.Entities.BuyerAggregate.PaymentMethod→Microsoft.eShopWeb.ApplicationCore.Entities.BaseEntity
- Direction
- Microsoft.eShopWeb.ApplicationCore.Entities.BuyerAggregate uses Microsoft.eShopWeb.ApplicationCore.Entities, so a change to Microsoft.eShopWeb.ApplicationCore.Entities can break Microsoft.eShopWeb.ApplicationCore.Entities.BuyerAggregate, while a change to Microsoft.eShopWeb.ApplicationCore.Entities.BuyerAggregate can't break Microsoft.eShopWeb.ApplicationCore.Entities.
- Position
- Below the diagonal: Microsoft.eShopWeb.ApplicationCore.Entities.BuyerAggregate uses a module listed above it, which is the healthy direction.
21→6 Microsoft.eShopWeb.ApplicationCore.Services uses Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate✕
- Connections
- 2 pairs of types, where a type in Microsoft.eShopWeb.ApplicationCore.Services uses a type in Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate.
- The types involved
Microsoft.eShopWeb.ApplicationCore.Services.BasketService→Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate.BasketMicrosoft.eShopWeb.ApplicationCore.Services.OrderService→Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate.Basket
- Direction
- Microsoft.eShopWeb.ApplicationCore.Services uses Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate, so a change to Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate can break Microsoft.eShopWeb.ApplicationCore.Services, while a change to Microsoft.eShopWeb.ApplicationCore.Services can't break Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate.
- Position
- Below the diagonal: Microsoft.eShopWeb.ApplicationCore.Services uses a module listed above it, which is the healthy direction.
21→7 Microsoft.eShopWeb.ApplicationCore.Services uses Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate✕
- Connections
- 2 pairs of types, where a type in Microsoft.eShopWeb.ApplicationCore.Services uses a type in Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.
- The types involved
Microsoft.eShopWeb.ApplicationCore.Services.OrderService→Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.AddressMicrosoft.eShopWeb.ApplicationCore.Services.OrderService→Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.Order
- Direction
- Microsoft.eShopWeb.ApplicationCore.Services uses Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate, so a change to Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate can break Microsoft.eShopWeb.ApplicationCore.Services, while a change to Microsoft.eShopWeb.ApplicationCore.Services can't break Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.
- Position
- Below the diagonal: Microsoft.eShopWeb.ApplicationCore.Services uses a module listed above it, which is the healthy direction.
21→11 Microsoft.eShopWeb.ApplicationCore.Services uses Microsoft.eShopWeb.ApplicationCore.Interfaces✕
- Connections
- 7 pairs of types, where a type in Microsoft.eShopWeb.ApplicationCore.Services uses a type in Microsoft.eShopWeb.ApplicationCore.Interfaces.
- The types involved
Microsoft.eShopWeb.ApplicationCore.Services.BasketService→Microsoft.eShopWeb.ApplicationCore.Interfaces.IAppLoggerMicrosoft.eShopWeb.ApplicationCore.Services.BasketService→Microsoft.eShopWeb.ApplicationCore.Interfaces.IBasketServiceMicrosoft.eShopWeb.ApplicationCore.Services.BasketService→Microsoft.eShopWeb.ApplicationCore.Interfaces.IRepositoryMicrosoft.eShopWeb.ApplicationCore.Services.OrderService→Microsoft.eShopWeb.ApplicationCore.Interfaces.IOrderServiceMicrosoft.eShopWeb.ApplicationCore.Services.OrderService→Microsoft.eShopWeb.ApplicationCore.Interfaces.IRepositoryMicrosoft.eShopWeb.ApplicationCore.Services.OrderService→Microsoft.eShopWeb.ApplicationCore.Interfaces.IUriComposerMicrosoft.eShopWeb.ApplicationCore.Services.UriComposer→Microsoft.eShopWeb.ApplicationCore.Interfaces.IUriComposer
- Direction
- Microsoft.eShopWeb.ApplicationCore.Services uses Microsoft.eShopWeb.ApplicationCore.Interfaces, so a change to Microsoft.eShopWeb.ApplicationCore.Interfaces can break Microsoft.eShopWeb.ApplicationCore.Services, while a change to Microsoft.eShopWeb.ApplicationCore.Services can't break Microsoft.eShopWeb.ApplicationCore.Interfaces.
- Position
- Below the diagonal: Microsoft.eShopWeb.ApplicationCore.Services uses a module listed above it, which is the healthy direction.
21→14 Microsoft.eShopWeb.ApplicationCore.Services uses Microsoft.eShopWeb.ApplicationCore.Entities✕
- Connections
- 1 pair of types, where a type in Microsoft.eShopWeb.ApplicationCore.Services uses a type in Microsoft.eShopWeb.ApplicationCore.Entities.
- The types involved
Microsoft.eShopWeb.ApplicationCore.Services.OrderService→Microsoft.eShopWeb.ApplicationCore.Entities.CatalogItem
- Direction
- Microsoft.eShopWeb.ApplicationCore.Services uses Microsoft.eShopWeb.ApplicationCore.Entities, so a change to Microsoft.eShopWeb.ApplicationCore.Entities can break Microsoft.eShopWeb.ApplicationCore.Services, while a change to Microsoft.eShopWeb.ApplicationCore.Services can't break Microsoft.eShopWeb.ApplicationCore.Entities.
- Position
- Below the diagonal: Microsoft.eShopWeb.ApplicationCore.Services uses a module listed above it, which is the healthy direction.
22→6 Microsoft.eShopWeb.Infrastructure.Data uses Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate✕
- Connections
- 2 pairs of types, where a type in Microsoft.eShopWeb.Infrastructure.Data uses a type in Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate.
- The types involved
Microsoft.eShopWeb.Infrastructure.Data.CatalogContext→Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate.BasketMicrosoft.eShopWeb.Infrastructure.Data.CatalogContext→Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate.BasketItem
- Direction
- Microsoft.eShopWeb.Infrastructure.Data uses Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate, so a change to Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate can break Microsoft.eShopWeb.Infrastructure.Data, while a change to Microsoft.eShopWeb.Infrastructure.Data can't break Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate.
- Position
- Below the diagonal: Microsoft.eShopWeb.Infrastructure.Data uses a module listed above it, which is the healthy direction.
22→7 Microsoft.eShopWeb.Infrastructure.Data uses Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate✕
- Connections
- 2 pairs of types, where a type in Microsoft.eShopWeb.Infrastructure.Data uses a type in Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.
- The types involved
Microsoft.eShopWeb.Infrastructure.Data.CatalogContext→Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.OrderMicrosoft.eShopWeb.Infrastructure.Data.CatalogContext→Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.OrderItem
- Direction
- Microsoft.eShopWeb.Infrastructure.Data uses Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate, so a change to Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate can break Microsoft.eShopWeb.Infrastructure.Data, while a change to Microsoft.eShopWeb.Infrastructure.Data can't break Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.
- Position
- Below the diagonal: Microsoft.eShopWeb.Infrastructure.Data uses a module listed above it, which is the healthy direction.
22→11 Microsoft.eShopWeb.Infrastructure.Data uses Microsoft.eShopWeb.ApplicationCore.Interfaces✕
- Connections
- 2 pairs of types, where a type in Microsoft.eShopWeb.Infrastructure.Data uses a type in Microsoft.eShopWeb.ApplicationCore.Interfaces.
- The types involved
Microsoft.eShopWeb.Infrastructure.Data.EfRepository→Microsoft.eShopWeb.ApplicationCore.Interfaces.IReadRepositoryMicrosoft.eShopWeb.Infrastructure.Data.EfRepository→Microsoft.eShopWeb.ApplicationCore.Interfaces.IRepository
- Direction
- Microsoft.eShopWeb.Infrastructure.Data uses Microsoft.eShopWeb.ApplicationCore.Interfaces, so a change to Microsoft.eShopWeb.ApplicationCore.Interfaces can break Microsoft.eShopWeb.Infrastructure.Data, while a change to Microsoft.eShopWeb.Infrastructure.Data can't break Microsoft.eShopWeb.ApplicationCore.Interfaces.
- Position
- Below the diagonal: Microsoft.eShopWeb.Infrastructure.Data uses a module listed above it, which is the healthy direction.
22→14 Microsoft.eShopWeb.Infrastructure.Data uses Microsoft.eShopWeb.ApplicationCore.Entities✕
- Connections
- 6 pairs of types, where a type in Microsoft.eShopWeb.Infrastructure.Data uses a type in Microsoft.eShopWeb.ApplicationCore.Entities.
- The types involved
Microsoft.eShopWeb.Infrastructure.Data.CatalogContext→Microsoft.eShopWeb.ApplicationCore.Entities.CatalogBrandMicrosoft.eShopWeb.Infrastructure.Data.CatalogContext→Microsoft.eShopWeb.ApplicationCore.Entities.CatalogItemMicrosoft.eShopWeb.Infrastructure.Data.CatalogContext→Microsoft.eShopWeb.ApplicationCore.Entities.CatalogTypeMicrosoft.eShopWeb.Infrastructure.Data.CatalogContextSeed→Microsoft.eShopWeb.ApplicationCore.Entities.CatalogBrandMicrosoft.eShopWeb.Infrastructure.Data.CatalogContextSeed→Microsoft.eShopWeb.ApplicationCore.Entities.CatalogItemMicrosoft.eShopWeb.Infrastructure.Data.CatalogContextSeed→Microsoft.eShopWeb.ApplicationCore.Entities.CatalogType
- Direction
- Microsoft.eShopWeb.Infrastructure.Data uses Microsoft.eShopWeb.ApplicationCore.Entities, so a change to Microsoft.eShopWeb.ApplicationCore.Entities can break Microsoft.eShopWeb.Infrastructure.Data, while a change to Microsoft.eShopWeb.Infrastructure.Data can't break Microsoft.eShopWeb.ApplicationCore.Entities.
- Position
- Below the diagonal: Microsoft.eShopWeb.Infrastructure.Data uses a module listed above it, which is the healthy direction.
23→6 Microsoft.eShopWeb.Infrastructure.Data.Config uses Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate✕
- Connections
- 2 pairs of types, where a type in Microsoft.eShopWeb.Infrastructure.Data.Config uses a type in Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate.
- The types involved
Microsoft.eShopWeb.Infrastructure.Data.Config.BasketConfiguration→Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate.BasketMicrosoft.eShopWeb.Infrastructure.Data.Config.BasketItemConfiguration→Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate.BasketItem
- Direction
- Microsoft.eShopWeb.Infrastructure.Data.Config uses Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate, so a change to Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate can break Microsoft.eShopWeb.Infrastructure.Data.Config, while a change to Microsoft.eShopWeb.Infrastructure.Data.Config can't break Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate.
- Position
- Below the diagonal: Microsoft.eShopWeb.Infrastructure.Data.Config uses a module listed above it, which is the healthy direction.
23→7 Microsoft.eShopWeb.Infrastructure.Data.Config uses Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate✕
- Connections
- 2 pairs of types, where a type in Microsoft.eShopWeb.Infrastructure.Data.Config uses a type in Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.
- The types involved
Microsoft.eShopWeb.Infrastructure.Data.Config.OrderConfiguration→Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.OrderMicrosoft.eShopWeb.Infrastructure.Data.Config.OrderItemConfiguration→Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.OrderItem
- Direction
- Microsoft.eShopWeb.Infrastructure.Data.Config uses Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate, so a change to Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate can break Microsoft.eShopWeb.Infrastructure.Data.Config, while a change to Microsoft.eShopWeb.Infrastructure.Data.Config can't break Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate.
- Position
- Below the diagonal: Microsoft.eShopWeb.Infrastructure.Data.Config uses a module listed above it, which is the healthy direction.
23→14 Microsoft.eShopWeb.Infrastructure.Data.Config uses Microsoft.eShopWeb.ApplicationCore.Entities✕
- Connections
- 3 pairs of types, where a type in Microsoft.eShopWeb.Infrastructure.Data.Config uses a type in Microsoft.eShopWeb.ApplicationCore.Entities.
- The types involved
Microsoft.eShopWeb.Infrastructure.Data.Config.CatalogBrandConfiguration→Microsoft.eShopWeb.ApplicationCore.Entities.CatalogBrandMicrosoft.eShopWeb.Infrastructure.Data.Config.CatalogItemConfiguration→Microsoft.eShopWeb.ApplicationCore.Entities.CatalogItemMicrosoft.eShopWeb.Infrastructure.Data.Config.CatalogTypeConfiguration→Microsoft.eShopWeb.ApplicationCore.Entities.CatalogType
- Direction
- Microsoft.eShopWeb.Infrastructure.Data.Config uses Microsoft.eShopWeb.ApplicationCore.Entities, so a change to Microsoft.eShopWeb.ApplicationCore.Entities can break Microsoft.eShopWeb.Infrastructure.Data.Config, while a change to Microsoft.eShopWeb.Infrastructure.Data.Config can't break Microsoft.eShopWeb.ApplicationCore.Entities.
- Position
- Below the diagonal: Microsoft.eShopWeb.Infrastructure.Data.Config uses a module listed above it, which is the healthy direction.
24→3 Microsoft.eShopWeb.PublicApi.AuthEndpoints uses Microsoft.eShopWeb.PublicApi✕
- Connections
- 2 pairs of types, where a type in Microsoft.eShopWeb.PublicApi.AuthEndpoints uses a type in Microsoft.eShopWeb.PublicApi.
- The types involved
Microsoft.eShopWeb.PublicApi.AuthEndpoints.AuthenticateRequest→Microsoft.eShopWeb.PublicApi.BaseRequestMicrosoft.eShopWeb.PublicApi.AuthEndpoints.AuthenticateResponse→Microsoft.eShopWeb.PublicApi.BaseResponse
- Direction
- Microsoft.eShopWeb.PublicApi.AuthEndpoints uses Microsoft.eShopWeb.PublicApi, so a change to Microsoft.eShopWeb.PublicApi can break Microsoft.eShopWeb.PublicApi.AuthEndpoints, while a change to Microsoft.eShopWeb.PublicApi.AuthEndpoints can't break Microsoft.eShopWeb.PublicApi.
- Position
- Below the diagonal: Microsoft.eShopWeb.PublicApi.AuthEndpoints uses a module listed above it, which is the healthy direction.
24→11 Microsoft.eShopWeb.PublicApi.AuthEndpoints uses Microsoft.eShopWeb.ApplicationCore.Interfaces✕
- Connections
- 1 pair of types, where a type in Microsoft.eShopWeb.PublicApi.AuthEndpoints uses a type in Microsoft.eShopWeb.ApplicationCore.Interfaces.
- The types involved
Microsoft.eShopWeb.PublicApi.AuthEndpoints.AuthenticateEndpoint→Microsoft.eShopWeb.ApplicationCore.Interfaces.ITokenClaimsService
- Direction
- Microsoft.eShopWeb.PublicApi.AuthEndpoints uses Microsoft.eShopWeb.ApplicationCore.Interfaces, so a change to Microsoft.eShopWeb.ApplicationCore.Interfaces can break Microsoft.eShopWeb.PublicApi.AuthEndpoints, while a change to Microsoft.eShopWeb.PublicApi.AuthEndpoints can't break Microsoft.eShopWeb.ApplicationCore.Interfaces.
- Position
- Below the diagonal: Microsoft.eShopWeb.PublicApi.AuthEndpoints uses a module listed above it, which is the healthy direction.
24→16 Microsoft.eShopWeb.PublicApi.AuthEndpoints uses Microsoft.eShopWeb.Infrastructure.Identity✕
- Connections
- 1 pair of types, where a type in Microsoft.eShopWeb.PublicApi.AuthEndpoints uses a type in Microsoft.eShopWeb.Infrastructure.Identity.
- The types involved
Microsoft.eShopWeb.PublicApi.AuthEndpoints.AuthenticateEndpoint→Microsoft.eShopWeb.Infrastructure.Identity.ApplicationUser
- Direction
- Microsoft.eShopWeb.PublicApi.AuthEndpoints uses Microsoft.eShopWeb.Infrastructure.Identity, so a change to Microsoft.eShopWeb.Infrastructure.Identity can break Microsoft.eShopWeb.PublicApi.AuthEndpoints, while a change to Microsoft.eShopWeb.PublicApi.AuthEndpoints can't break Microsoft.eShopWeb.Infrastructure.Identity.
- Position
- Below the diagonal: Microsoft.eShopWeb.PublicApi.AuthEndpoints uses a module listed above it, which is the healthy direction.
25→3 Microsoft.eShopWeb.PublicApi.CatalogBrandEndpoints uses Microsoft.eShopWeb.PublicApi✕
- Connections
- 1 pair of types, where a type in Microsoft.eShopWeb.PublicApi.CatalogBrandEndpoints uses a type in Microsoft.eShopWeb.PublicApi.
- The types involved
Microsoft.eShopWeb.PublicApi.CatalogBrandEndpoints.ListCatalogBrandsResponse→Microsoft.eShopWeb.PublicApi.BaseResponse
- Direction
- Microsoft.eShopWeb.PublicApi.CatalogBrandEndpoints uses Microsoft.eShopWeb.PublicApi, so a change to Microsoft.eShopWeb.PublicApi can break Microsoft.eShopWeb.PublicApi.CatalogBrandEndpoints, while a change to Microsoft.eShopWeb.PublicApi.CatalogBrandEndpoints can't break Microsoft.eShopWeb.PublicApi.
- Position
- Below the diagonal: Microsoft.eShopWeb.PublicApi.CatalogBrandEndpoints uses a module listed above it, which is the healthy direction.
25→11 Microsoft.eShopWeb.PublicApi.CatalogBrandEndpoints uses Microsoft.eShopWeb.ApplicationCore.Interfaces✕
- Connections
- 1 pair of types, where a type in Microsoft.eShopWeb.PublicApi.CatalogBrandEndpoints uses a type in Microsoft.eShopWeb.ApplicationCore.Interfaces.
- The types involved
Microsoft.eShopWeb.PublicApi.CatalogBrandEndpoints.CatalogBrandListEndpoint→Microsoft.eShopWeb.ApplicationCore.Interfaces.IRepository
- Direction
- Microsoft.eShopWeb.PublicApi.CatalogBrandEndpoints uses Microsoft.eShopWeb.ApplicationCore.Interfaces, so a change to Microsoft.eShopWeb.ApplicationCore.Interfaces can break Microsoft.eShopWeb.PublicApi.CatalogBrandEndpoints, while a change to Microsoft.eShopWeb.PublicApi.CatalogBrandEndpoints can't break Microsoft.eShopWeb.ApplicationCore.Interfaces.
- Position
- Below the diagonal: Microsoft.eShopWeb.PublicApi.CatalogBrandEndpoints uses a module listed above it, which is the healthy direction.
25→14 Microsoft.eShopWeb.PublicApi.CatalogBrandEndpoints uses Microsoft.eShopWeb.ApplicationCore.Entities✕
- Connections
- 1 pair of types, where a type in Microsoft.eShopWeb.PublicApi.CatalogBrandEndpoints uses a type in Microsoft.eShopWeb.ApplicationCore.Entities.
- The types involved
Microsoft.eShopWeb.PublicApi.CatalogBrandEndpoints.CatalogBrandListEndpoint→Microsoft.eShopWeb.ApplicationCore.Entities.CatalogBrand
- Direction
- Microsoft.eShopWeb.PublicApi.CatalogBrandEndpoints uses Microsoft.eShopWeb.ApplicationCore.Entities, so a change to Microsoft.eShopWeb.ApplicationCore.Entities can break Microsoft.eShopWeb.PublicApi.CatalogBrandEndpoints, while a change to Microsoft.eShopWeb.PublicApi.CatalogBrandEndpoints can't break Microsoft.eShopWeb.ApplicationCore.Entities.
- Position
- Below the diagonal: Microsoft.eShopWeb.PublicApi.CatalogBrandEndpoints uses a module listed above it, which is the healthy direction.
26→3 Microsoft.eShopWeb.PublicApi.CatalogItemEndpoints uses Microsoft.eShopWeb.PublicApi✕
- Connections
- 9 pairs of types, where a type in Microsoft.eShopWeb.PublicApi.CatalogItemEndpoints uses a type in Microsoft.eShopWeb.PublicApi.
- The types involved
Microsoft.eShopWeb.PublicApi.CatalogItemEndpoints.CreateCatalogItemRequest→Microsoft.eShopWeb.PublicApi.BaseRequestMicrosoft.eShopWeb.PublicApi.CatalogItemEndpoints.CreateCatalogItemResponse→Microsoft.eShopWeb.PublicApi.BaseResponseMicrosoft.eShopWeb.PublicApi.CatalogItemEndpoints.DeleteCatalogItemRequest→Microsoft.eShopWeb.PublicApi.BaseRequestMicrosoft.eShopWeb.PublicApi.CatalogItemEndpoints.GetByIdCatalogItemRequest→Microsoft.eShopWeb.PublicApi.BaseRequestMicrosoft.eShopWeb.PublicApi.CatalogItemEndpoints.GetByIdCatalogItemResponse→Microsoft.eShopWeb.PublicApi.BaseResponseMicrosoft.eShopWeb.PublicApi.CatalogItemEndpoints.ListPagedCatalogItemRequest→Microsoft.eShopWeb.PublicApi.BaseRequestMicrosoft.eShopWeb.PublicApi.CatalogItemEndpoints.ListPagedCatalogItemResponse→Microsoft.eShopWeb.PublicApi.BaseResponseMicrosoft.eShopWeb.PublicApi.CatalogItemEndpoints.UpdateCatalogItemRequest→Microsoft.eShopWeb.PublicApi.BaseRequestMicrosoft.eShopWeb.PublicApi.CatalogItemEndpoints.UpdateCatalogItemResponse→Microsoft.eShopWeb.PublicApi.BaseResponse
- Direction
- Microsoft.eShopWeb.PublicApi.CatalogItemEndpoints uses Microsoft.eShopWeb.PublicApi, so a change to Microsoft.eShopWeb.PublicApi can break Microsoft.eShopWeb.PublicApi.CatalogItemEndpoints, while a change to Microsoft.eShopWeb.PublicApi.CatalogItemEndpoints can't break Microsoft.eShopWeb.PublicApi.
- Position
- Below the diagonal: Microsoft.eShopWeb.PublicApi.CatalogItemEndpoints uses a module listed above it, which is the healthy direction.
26→11 Microsoft.eShopWeb.PublicApi.CatalogItemEndpoints uses Microsoft.eShopWeb.ApplicationCore.Interfaces✕
- Connections
- 9 pairs of types, where a type in Microsoft.eShopWeb.PublicApi.CatalogItemEndpoints uses a type in Microsoft.eShopWeb.ApplicationCore.Interfaces.
- The types involved
Microsoft.eShopWeb.PublicApi.CatalogItemEndpoints.CatalogItemGetByIdEndpoint→Microsoft.eShopWeb.ApplicationCore.Interfaces.IRepositoryMicrosoft.eShopWeb.PublicApi.CatalogItemEndpoints.CatalogItemGetByIdEndpoint→Microsoft.eShopWeb.ApplicationCore.Interfaces.IUriComposerMicrosoft.eShopWeb.PublicApi.CatalogItemEndpoints.CatalogItemListPagedEndpoint→Microsoft.eShopWeb.ApplicationCore.Interfaces.IRepositoryMicrosoft.eShopWeb.PublicApi.CatalogItemEndpoints.CatalogItemListPagedEndpoint→Microsoft.eShopWeb.ApplicationCore.Interfaces.IUriComposerMicrosoft.eShopWeb.PublicApi.CatalogItemEndpoints.CreateCatalogItemEndpoint→Microsoft.eShopWeb.ApplicationCore.Interfaces.IRepositoryMicrosoft.eShopWeb.PublicApi.CatalogItemEndpoints.CreateCatalogItemEndpoint→Microsoft.eShopWeb.ApplicationCore.Interfaces.IUriComposerMicrosoft.eShopWeb.PublicApi.CatalogItemEndpoints.DeleteCatalogItemEndpoint→Microsoft.eShopWeb.ApplicationCore.Interfaces.IRepositoryMicrosoft.eShopWeb.PublicApi.CatalogItemEndpoints.UpdateCatalogItemEndpoint→Microsoft.eShopWeb.ApplicationCore.Interfaces.IRepositoryMicrosoft.eShopWeb.PublicApi.CatalogItemEndpoints.UpdateCatalogItemEndpoint→Microsoft.eShopWeb.ApplicationCore.Interfaces.IUriComposer
- Direction
- Microsoft.eShopWeb.PublicApi.CatalogItemEndpoints uses Microsoft.eShopWeb.ApplicationCore.Interfaces, so a change to Microsoft.eShopWeb.ApplicationCore.Interfaces can break Microsoft.eShopWeb.PublicApi.CatalogItemEndpoints, while a change to Microsoft.eShopWeb.PublicApi.CatalogItemEndpoints can't break Microsoft.eShopWeb.ApplicationCore.Interfaces.
- Position
- Below the diagonal: Microsoft.eShopWeb.PublicApi.CatalogItemEndpoints uses a module listed above it, which is the healthy direction.
26→14 Microsoft.eShopWeb.PublicApi.CatalogItemEndpoints uses Microsoft.eShopWeb.ApplicationCore.Entities✕
- Connections
- 5 pairs of types, where a type in Microsoft.eShopWeb.PublicApi.CatalogItemEndpoints uses a type in Microsoft.eShopWeb.ApplicationCore.Entities.
- The types involved
Microsoft.eShopWeb.PublicApi.CatalogItemEndpoints.CatalogItemGetByIdEndpoint→Microsoft.eShopWeb.ApplicationCore.Entities.CatalogItemMicrosoft.eShopWeb.PublicApi.CatalogItemEndpoints.CatalogItemListPagedEndpoint→Microsoft.eShopWeb.ApplicationCore.Entities.CatalogItemMicrosoft.eShopWeb.PublicApi.CatalogItemEndpoints.CreateCatalogItemEndpoint→Microsoft.eShopWeb.ApplicationCore.Entities.CatalogItemMicrosoft.eShopWeb.PublicApi.CatalogItemEndpoints.DeleteCatalogItemEndpoint→Microsoft.eShopWeb.ApplicationCore.Entities.CatalogItemMicrosoft.eShopWeb.PublicApi.CatalogItemEndpoints.UpdateCatalogItemEndpoint→Microsoft.eShopWeb.ApplicationCore.Entities.CatalogItem
- Direction
- Microsoft.eShopWeb.PublicApi.CatalogItemEndpoints uses Microsoft.eShopWeb.ApplicationCore.Entities, so a change to Microsoft.eShopWeb.ApplicationCore.Entities can break Microsoft.eShopWeb.PublicApi.CatalogItemEndpoints, while a change to Microsoft.eShopWeb.PublicApi.CatalogItemEndpoints can't break Microsoft.eShopWeb.ApplicationCore.Entities.
- Position
- Below the diagonal: Microsoft.eShopWeb.PublicApi.CatalogItemEndpoints uses a module listed above it, which is the healthy direction.
27→3 Microsoft.eShopWeb.PublicApi.CatalogTypeEndpoints uses Microsoft.eShopWeb.PublicApi✕
- Connections
- 1 pair of types, where a type in Microsoft.eShopWeb.PublicApi.CatalogTypeEndpoints uses a type in Microsoft.eShopWeb.PublicApi.
- The types involved
Microsoft.eShopWeb.PublicApi.CatalogTypeEndpoints.ListCatalogTypesResponse→Microsoft.eShopWeb.PublicApi.BaseResponse
- Direction
- Microsoft.eShopWeb.PublicApi.CatalogTypeEndpoints uses Microsoft.eShopWeb.PublicApi, so a change to Microsoft.eShopWeb.PublicApi can break Microsoft.eShopWeb.PublicApi.CatalogTypeEndpoints, while a change to Microsoft.eShopWeb.PublicApi.CatalogTypeEndpoints can't break Microsoft.eShopWeb.PublicApi.
- Position
- Below the diagonal: Microsoft.eShopWeb.PublicApi.CatalogTypeEndpoints uses a module listed above it, which is the healthy direction.
27→11 Microsoft.eShopWeb.PublicApi.CatalogTypeEndpoints uses Microsoft.eShopWeb.ApplicationCore.Interfaces✕
- Connections
- 1 pair of types, where a type in Microsoft.eShopWeb.PublicApi.CatalogTypeEndpoints uses a type in Microsoft.eShopWeb.ApplicationCore.Interfaces.
- The types involved
Microsoft.eShopWeb.PublicApi.CatalogTypeEndpoints.CatalogTypeListEndpoint→Microsoft.eShopWeb.ApplicationCore.Interfaces.IRepository
- Direction
- Microsoft.eShopWeb.PublicApi.CatalogTypeEndpoints uses Microsoft.eShopWeb.ApplicationCore.Interfaces, so a change to Microsoft.eShopWeb.ApplicationCore.Interfaces can break Microsoft.eShopWeb.PublicApi.CatalogTypeEndpoints, while a change to Microsoft.eShopWeb.PublicApi.CatalogTypeEndpoints can't break Microsoft.eShopWeb.ApplicationCore.Interfaces.
- Position
- Below the diagonal: Microsoft.eShopWeb.PublicApi.CatalogTypeEndpoints uses a module listed above it, which is the healthy direction.
27→14 Microsoft.eShopWeb.PublicApi.CatalogTypeEndpoints uses Microsoft.eShopWeb.ApplicationCore.Entities✕
- Connections
- 1 pair of types, where a type in Microsoft.eShopWeb.PublicApi.CatalogTypeEndpoints uses a type in Microsoft.eShopWeb.ApplicationCore.Entities.
- The types involved
Microsoft.eShopWeb.PublicApi.CatalogTypeEndpoints.CatalogTypeListEndpoint→Microsoft.eShopWeb.ApplicationCore.Entities.CatalogType
- Direction
- Microsoft.eShopWeb.PublicApi.CatalogTypeEndpoints uses Microsoft.eShopWeb.ApplicationCore.Entities, so a change to Microsoft.eShopWeb.ApplicationCore.Entities can break Microsoft.eShopWeb.PublicApi.CatalogTypeEndpoints, while a change to Microsoft.eShopWeb.PublicApi.CatalogTypeEndpoints can't break Microsoft.eShopWeb.ApplicationCore.Entities.
- Position
- Below the diagonal: Microsoft.eShopWeb.PublicApi.CatalogTypeEndpoints uses a module listed above it, which is the healthy direction.
28→3 Microsoft.eShopWeb.PublicApi.RoleManagementEndpoints uses Microsoft.eShopWeb.PublicApi✕
- Connections
- 8 pairs of types, where a type in Microsoft.eShopWeb.PublicApi.RoleManagementEndpoints uses a type in Microsoft.eShopWeb.PublicApi.
- The types involved
Microsoft.eShopWeb.PublicApi.RoleManagementEndpoints.CreateRoleRequest→Microsoft.eShopWeb.PublicApi.BaseRequestMicrosoft.eShopWeb.PublicApi.RoleManagementEndpoints.CreateRoleResponse→Microsoft.eShopWeb.PublicApi.BaseResponseMicrosoft.eShopWeb.PublicApi.RoleManagementEndpoints.DeleteRoleRequest→Microsoft.eShopWeb.PublicApi.BaseRequestMicrosoft.eShopWeb.PublicApi.RoleManagementEndpoints.GetByIdRoleRequest→Microsoft.eShopWeb.PublicApi.BaseRequestMicrosoft.eShopWeb.PublicApi.RoleManagementEndpoints.GetByIdRoleResponse→Microsoft.eShopWeb.PublicApi.BaseResponseMicrosoft.eShopWeb.PublicApi.RoleManagementEndpoints.RoleListResponse→Microsoft.eShopWeb.PublicApi.BaseResponseMicrosoft.eShopWeb.PublicApi.RoleManagementEndpoints.UpdateRoleRequest→Microsoft.eShopWeb.PublicApi.BaseRequestMicrosoft.eShopWeb.PublicApi.RoleManagementEndpoints.UpdateRoleResponse→Microsoft.eShopWeb.PublicApi.BaseResponse
- Direction
- Microsoft.eShopWeb.PublicApi.RoleManagementEndpoints uses Microsoft.eShopWeb.PublicApi, so a change to Microsoft.eShopWeb.PublicApi can break Microsoft.eShopWeb.PublicApi.RoleManagementEndpoints, while a change to Microsoft.eShopWeb.PublicApi.RoleManagementEndpoints can't break Microsoft.eShopWeb.PublicApi.
- Position
- Below the diagonal: Microsoft.eShopWeb.PublicApi.RoleManagementEndpoints uses a module listed above it, which is the healthy direction.
28→16 Microsoft.eShopWeb.PublicApi.RoleManagementEndpoints uses Microsoft.eShopWeb.Infrastructure.Identity✕
- Connections
- 1 pair of types, where a type in Microsoft.eShopWeb.PublicApi.RoleManagementEndpoints uses a type in Microsoft.eShopWeb.Infrastructure.Identity.
- The types involved
Microsoft.eShopWeb.PublicApi.RoleManagementEndpoints.DeleteRoleEndpoint→Microsoft.eShopWeb.Infrastructure.Identity.ApplicationUser
- Direction
- Microsoft.eShopWeb.PublicApi.RoleManagementEndpoints uses Microsoft.eShopWeb.Infrastructure.Identity, so a change to Microsoft.eShopWeb.Infrastructure.Identity can break Microsoft.eShopWeb.PublicApi.RoleManagementEndpoints, while a change to Microsoft.eShopWeb.PublicApi.RoleManagementEndpoints can't break Microsoft.eShopWeb.Infrastructure.Identity.
- Position
- Below the diagonal: Microsoft.eShopWeb.PublicApi.RoleManagementEndpoints uses a module listed above it, which is the healthy direction.
29→3 Microsoft.eShopWeb.PublicApi.RoleMembershipEndpoints uses Microsoft.eShopWeb.PublicApi✕
- Connections
- 3 pairs of types, where a type in Microsoft.eShopWeb.PublicApi.RoleMembershipEndpoints uses a type in Microsoft.eShopWeb.PublicApi.
- The types involved
Microsoft.eShopWeb.PublicApi.RoleMembershipEndpoints.DeleteUserFromRoleRequest→Microsoft.eShopWeb.PublicApi.BaseRequestMicrosoft.eShopWeb.PublicApi.RoleMembershipEndpoints.GetRoleMembershipRequest→Microsoft.eShopWeb.PublicApi.BaseRequestMicrosoft.eShopWeb.PublicApi.RoleMembershipEndpoints.GetRoleMembershipResponse→Microsoft.eShopWeb.PublicApi.BaseResponse
- Direction
- Microsoft.eShopWeb.PublicApi.RoleMembershipEndpoints uses Microsoft.eShopWeb.PublicApi, so a change to Microsoft.eShopWeb.PublicApi can break Microsoft.eShopWeb.PublicApi.RoleMembershipEndpoints, while a change to Microsoft.eShopWeb.PublicApi.RoleMembershipEndpoints can't break Microsoft.eShopWeb.PublicApi.
- Position
- Below the diagonal: Microsoft.eShopWeb.PublicApi.RoleMembershipEndpoints uses a module listed above it, which is the healthy direction.
29→16 Microsoft.eShopWeb.PublicApi.RoleMembershipEndpoints uses Microsoft.eShopWeb.Infrastructure.Identity✕
- Connections
- 3 pairs of types, where a type in Microsoft.eShopWeb.PublicApi.RoleMembershipEndpoints uses a type in Microsoft.eShopWeb.Infrastructure.Identity.
- The types involved
Microsoft.eShopWeb.PublicApi.RoleMembershipEndpoints.DeleteUserFromRoleEndpoint→Microsoft.eShopWeb.Infrastructure.Identity.ApplicationUserMicrosoft.eShopWeb.PublicApi.RoleMembershipEndpoints.GetRoleMembershipResponse→Microsoft.eShopWeb.Infrastructure.Identity.ApplicationUserMicrosoft.eShopWeb.PublicApi.RoleMembershipEndpoints.RoleMembershipGetByNameEndpoint→Microsoft.eShopWeb.Infrastructure.Identity.ApplicationUser
- Direction
- Microsoft.eShopWeb.PublicApi.RoleMembershipEndpoints uses Microsoft.eShopWeb.Infrastructure.Identity, so a change to Microsoft.eShopWeb.Infrastructure.Identity can break Microsoft.eShopWeb.PublicApi.RoleMembershipEndpoints, while a change to Microsoft.eShopWeb.PublicApi.RoleMembershipEndpoints can't break Microsoft.eShopWeb.Infrastructure.Identity.
- Position
- Below the diagonal: Microsoft.eShopWeb.PublicApi.RoleMembershipEndpoints uses a module listed above it, which is the healthy direction.
30→3 Microsoft.eShopWeb.PublicApi.UserManagementEndpoints uses Microsoft.eShopWeb.PublicApi✕
- Connections
- 10 pairs of types, where a type in Microsoft.eShopWeb.PublicApi.UserManagementEndpoints uses a type in Microsoft.eShopWeb.PublicApi.
- The types involved
Microsoft.eShopWeb.PublicApi.UserManagementEndpoints.CreateUserRequest→Microsoft.eShopWeb.PublicApi.BaseRequestMicrosoft.eShopWeb.PublicApi.UserManagementEndpoints.CreateUserResponse→Microsoft.eShopWeb.PublicApi.BaseResponseMicrosoft.eShopWeb.PublicApi.UserManagementEndpoints.DeleteUserRequest→Microsoft.eShopWeb.PublicApi.BaseRequestMicrosoft.eShopWeb.PublicApi.UserManagementEndpoints.GetByIdUserRequest→Microsoft.eShopWeb.PublicApi.BaseRequestMicrosoft.eShopWeb.PublicApi.UserManagementEndpoints.GetByUserNameUserRequest→Microsoft.eShopWeb.PublicApi.BaseRequestMicrosoft.eShopWeb.PublicApi.UserManagementEndpoints.GetRolesByUserIdRequest→Microsoft.eShopWeb.PublicApi.BaseRequestMicrosoft.eShopWeb.PublicApi.UserManagementEndpoints.SaveRolesForUserRequest→Microsoft.eShopWeb.PublicApi.BaseRequestMicrosoft.eShopWeb.PublicApi.UserManagementEndpoints.UpdateUserRequest→Microsoft.eShopWeb.PublicApi.BaseRequestMicrosoft.eShopWeb.PublicApi.UserManagementEndpoints.UpdateUserResponse→Microsoft.eShopWeb.PublicApi.BaseResponseMicrosoft.eShopWeb.PublicApi.UserManagementEndpoints.UserListResponse→Microsoft.eShopWeb.PublicApi.BaseResponse
- Direction
- Microsoft.eShopWeb.PublicApi.UserManagementEndpoints uses Microsoft.eShopWeb.PublicApi, so a change to Microsoft.eShopWeb.PublicApi can break Microsoft.eShopWeb.PublicApi.UserManagementEndpoints, while a change to Microsoft.eShopWeb.PublicApi.UserManagementEndpoints can't break Microsoft.eShopWeb.PublicApi.
- Position
- Below the diagonal: Microsoft.eShopWeb.PublicApi.UserManagementEndpoints uses a module listed above it, which is the healthy direction.
30→8 Microsoft.eShopWeb.PublicApi.UserManagementEndpoints uses Microsoft.eShopWeb.PublicApi.UserManagementEndpoints.Models✕
- Connections
- 3 pairs of types, where a type in Microsoft.eShopWeb.PublicApi.UserManagementEndpoints uses a type in Microsoft.eShopWeb.PublicApi.UserManagementEndpoints.Models.
- The types involved
Microsoft.eShopWeb.PublicApi.UserManagementEndpoints.UserGetByIdEndpoint→Microsoft.eShopWeb.PublicApi.UserManagementEndpoints.Models.GetUserResponseMicrosoft.eShopWeb.PublicApi.UserManagementEndpoints.UserGetByUserNameEndpoint→Microsoft.eShopWeb.PublicApi.UserManagementEndpoints.Models.GetUserResponseMicrosoft.eShopWeb.PublicApi.UserManagementEndpoints.UserGetRolesByIdEndpoint→Microsoft.eShopWeb.PublicApi.UserManagementEndpoints.Models.GetUserRolesResponse
- Direction
- Microsoft.eShopWeb.PublicApi.UserManagementEndpoints uses Microsoft.eShopWeb.PublicApi.UserManagementEndpoints.Models, so a change to Microsoft.eShopWeb.PublicApi.UserManagementEndpoints.Models can break Microsoft.eShopWeb.PublicApi.UserManagementEndpoints, while a change to Microsoft.eShopWeb.PublicApi.UserManagementEndpoints can't break Microsoft.eShopWeb.PublicApi.UserManagementEndpoints.Models.
- Position
- Below the diagonal: Microsoft.eShopWeb.PublicApi.UserManagementEndpoints uses a module listed above it, which is the healthy direction.
30→16 Microsoft.eShopWeb.PublicApi.UserManagementEndpoints uses Microsoft.eShopWeb.Infrastructure.Identity✕
- Connections
- 9 pairs of types, where a type in Microsoft.eShopWeb.PublicApi.UserManagementEndpoints uses a type in Microsoft.eShopWeb.Infrastructure.Identity.
- The types involved
Microsoft.eShopWeb.PublicApi.UserManagementEndpoints.CreateUserEndpoint→Microsoft.eShopWeb.Infrastructure.Identity.ApplicationUserMicrosoft.eShopWeb.PublicApi.UserManagementEndpoints.DeleteUserEndpoint→Microsoft.eShopWeb.Infrastructure.Identity.ApplicationUserMicrosoft.eShopWeb.PublicApi.UserManagementEndpoints.SaveRolesForUserEndpoint→Microsoft.eShopWeb.Infrastructure.Identity.ApplicationUserMicrosoft.eShopWeb.PublicApi.UserManagementEndpoints.UpdateRoleEndpoint→Microsoft.eShopWeb.Infrastructure.Identity.ApplicationUserMicrosoft.eShopWeb.PublicApi.UserManagementEndpoints.UpdateUserResponse→Microsoft.eShopWeb.Infrastructure.Identity.ApplicationUserMicrosoft.eShopWeb.PublicApi.UserManagementEndpoints.UserGetByIdEndpoint→Microsoft.eShopWeb.Infrastructure.Identity.ApplicationUserMicrosoft.eShopWeb.PublicApi.UserManagementEndpoints.UserGetByUserNameEndpoint→Microsoft.eShopWeb.Infrastructure.Identity.ApplicationUserMicrosoft.eShopWeb.PublicApi.UserManagementEndpoints.UserGetRolesByIdEndpoint→Microsoft.eShopWeb.Infrastructure.Identity.ApplicationUserMicrosoft.eShopWeb.PublicApi.UserManagementEndpoints.UserListEndpoint→Microsoft.eShopWeb.Infrastructure.Identity.ApplicationUser
- Direction
- Microsoft.eShopWeb.PublicApi.UserManagementEndpoints uses Microsoft.eShopWeb.Infrastructure.Identity, so a change to Microsoft.eShopWeb.Infrastructure.Identity can break Microsoft.eShopWeb.PublicApi.UserManagementEndpoints, while a change to Microsoft.eShopWeb.PublicApi.UserManagementEndpoints can't break Microsoft.eShopWeb.Infrastructure.Identity.
- Position
- Below the diagonal: Microsoft.eShopWeb.PublicApi.UserManagementEndpoints uses a module listed above it, which is the healthy direction.
31→11 Microsoft.eShopWeb.Web.Areas.Identity.Pages.Account uses Microsoft.eShopWeb.ApplicationCore.Interfaces✕
- Connections
- 1 pair of types, where a type in Microsoft.eShopWeb.Web.Areas.Identity.Pages.Account uses a type in Microsoft.eShopWeb.ApplicationCore.Interfaces.
- The types involved
Microsoft.eShopWeb.Web.Areas.Identity.Pages.Account.LoginModel→Microsoft.eShopWeb.ApplicationCore.Interfaces.IBasketService
- Direction
- Microsoft.eShopWeb.Web.Areas.Identity.Pages.Account uses Microsoft.eShopWeb.ApplicationCore.Interfaces, so a change to Microsoft.eShopWeb.ApplicationCore.Interfaces can break Microsoft.eShopWeb.Web.Areas.Identity.Pages.Account, while a change to Microsoft.eShopWeb.Web.Areas.Identity.Pages.Account can't break Microsoft.eShopWeb.ApplicationCore.Interfaces.
- Position
- Below the diagonal: Microsoft.eShopWeb.Web.Areas.Identity.Pages.Account uses a module listed above it, which is the healthy direction.
31→16 Microsoft.eShopWeb.Web.Areas.Identity.Pages.Account uses Microsoft.eShopWeb.Infrastructure.Identity✕
- Connections
- 4 pairs of types, where a type in Microsoft.eShopWeb.Web.Areas.Identity.Pages.Account uses a type in Microsoft.eShopWeb.Infrastructure.Identity.
- The types involved
Microsoft.eShopWeb.Web.Areas.Identity.Pages.Account.ConfirmEmailModel→Microsoft.eShopWeb.Infrastructure.Identity.ApplicationUserMicrosoft.eShopWeb.Web.Areas.Identity.Pages.Account.LoginModel→Microsoft.eShopWeb.Infrastructure.Identity.ApplicationUserMicrosoft.eShopWeb.Web.Areas.Identity.Pages.Account.LogoutModel→Microsoft.eShopWeb.Infrastructure.Identity.ApplicationUserMicrosoft.eShopWeb.Web.Areas.Identity.Pages.Account.RegisterModel→Microsoft.eShopWeb.Infrastructure.Identity.ApplicationUser
- Direction
- Microsoft.eShopWeb.Web.Areas.Identity.Pages.Account uses Microsoft.eShopWeb.Infrastructure.Identity, so a change to Microsoft.eShopWeb.Infrastructure.Identity can break Microsoft.eShopWeb.Web.Areas.Identity.Pages.Account, while a change to Microsoft.eShopWeb.Web.Areas.Identity.Pages.Account can't break Microsoft.eShopWeb.Infrastructure.Identity.
- Position
- Below the diagonal: Microsoft.eShopWeb.Web.Areas.Identity.Pages.Account uses a module listed above it, which is the healthy direction.
32→11 Microsoft.eShopWeb.Web.Controllers uses Microsoft.eShopWeb.ApplicationCore.Interfaces✕
- Connections
- 3 pairs of types, where a type in Microsoft.eShopWeb.Web.Controllers uses a type in Microsoft.eShopWeb.ApplicationCore.Interfaces.
- The types involved
Microsoft.eShopWeb.Web.Controllers.ManageController→Microsoft.eShopWeb.ApplicationCore.Interfaces.IAppLoggerMicrosoft.eShopWeb.Web.Controllers.ManageController→Microsoft.eShopWeb.ApplicationCore.Interfaces.IEmailSenderMicrosoft.eShopWeb.Web.Controllers.UserController→Microsoft.eShopWeb.ApplicationCore.Interfaces.ITokenClaimsService
- Direction
- Microsoft.eShopWeb.Web.Controllers uses Microsoft.eShopWeb.ApplicationCore.Interfaces, so a change to Microsoft.eShopWeb.ApplicationCore.Interfaces can break Microsoft.eShopWeb.Web.Controllers, while a change to Microsoft.eShopWeb.Web.Controllers can't break Microsoft.eShopWeb.ApplicationCore.Interfaces.
- Position
- Below the diagonal: Microsoft.eShopWeb.Web.Controllers uses a module listed above it, which is the healthy direction.
32→16 Microsoft.eShopWeb.Web.Controllers uses Microsoft.eShopWeb.Infrastructure.Identity✕
- Connections
- 2 pairs of types, where a type in Microsoft.eShopWeb.Web.Controllers uses a type in Microsoft.eShopWeb.Infrastructure.Identity.
- The types involved
Microsoft.eShopWeb.Web.Controllers.ManageController→Microsoft.eShopWeb.Infrastructure.Identity.ApplicationUserMicrosoft.eShopWeb.Web.Controllers.UserController→Microsoft.eShopWeb.Infrastructure.Identity.ApplicationUser
- Direction
- Microsoft.eShopWeb.Web.Controllers uses Microsoft.eShopWeb.Infrastructure.Identity, so a change to Microsoft.eShopWeb.Infrastructure.Identity can break Microsoft.eShopWeb.Web.Controllers, while a change to Microsoft.eShopWeb.Web.Controllers can't break Microsoft.eShopWeb.Infrastructure.Identity.
- Position
- Below the diagonal: Microsoft.eShopWeb.Web.Controllers uses a module listed above it, which is the healthy direction.
33→11 Microsoft.eShopWeb.Web.Pages.Basket uses Microsoft.eShopWeb.ApplicationCore.Interfaces✕
- Connections
- 5 pairs of types, where a type in Microsoft.eShopWeb.Web.Pages.Basket uses a type in Microsoft.eShopWeb.ApplicationCore.Interfaces.
- The types involved
Microsoft.eShopWeb.Web.Pages.Basket.CheckoutModel→Microsoft.eShopWeb.ApplicationCore.Interfaces.IAppLoggerMicrosoft.eShopWeb.Web.Pages.Basket.CheckoutModel→Microsoft.eShopWeb.ApplicationCore.Interfaces.IBasketServiceMicrosoft.eShopWeb.Web.Pages.Basket.CheckoutModel→Microsoft.eShopWeb.ApplicationCore.Interfaces.IOrderServiceMicrosoft.eShopWeb.Web.Pages.Basket.IndexModel→Microsoft.eShopWeb.ApplicationCore.Interfaces.IBasketServiceMicrosoft.eShopWeb.Web.Pages.Basket.IndexModel→Microsoft.eShopWeb.ApplicationCore.Interfaces.IRepository
- Direction
- Microsoft.eShopWeb.Web.Pages.Basket uses Microsoft.eShopWeb.ApplicationCore.Interfaces, so a change to Microsoft.eShopWeb.ApplicationCore.Interfaces can break Microsoft.eShopWeb.Web.Pages.Basket, while a change to Microsoft.eShopWeb.Web.Pages.Basket can't break Microsoft.eShopWeb.ApplicationCore.Interfaces.
- Position
- Below the diagonal: Microsoft.eShopWeb.Web.Pages.Basket uses a module listed above it, which is the healthy direction.
33→12 Microsoft.eShopWeb.Web.Pages.Basket uses Microsoft.eShopWeb.Web.ViewModels✕
- Connections
- 1 pair of types, where a type in Microsoft.eShopWeb.Web.Pages.Basket uses a type in Microsoft.eShopWeb.Web.ViewModels.
- The types involved
Microsoft.eShopWeb.Web.Pages.Basket.IndexModel→Microsoft.eShopWeb.Web.ViewModels.CatalogItemViewModel
- Direction
- Microsoft.eShopWeb.Web.Pages.Basket uses Microsoft.eShopWeb.Web.ViewModels, so a change to Microsoft.eShopWeb.Web.ViewModels can break Microsoft.eShopWeb.Web.Pages.Basket, while a change to Microsoft.eShopWeb.Web.Pages.Basket can't break Microsoft.eShopWeb.Web.ViewModels.
- Position
- Below the diagonal: Microsoft.eShopWeb.Web.Pages.Basket uses a module listed above it, which is the healthy direction.
33→14 Microsoft.eShopWeb.Web.Pages.Basket uses Microsoft.eShopWeb.ApplicationCore.Entities✕
- Connections
- 1 pair of types, where a type in Microsoft.eShopWeb.Web.Pages.Basket uses a type in Microsoft.eShopWeb.ApplicationCore.Entities.
- The types involved
Microsoft.eShopWeb.Web.Pages.Basket.IndexModel→Microsoft.eShopWeb.ApplicationCore.Entities.CatalogItem
- Direction
- Microsoft.eShopWeb.Web.Pages.Basket uses Microsoft.eShopWeb.ApplicationCore.Entities, so a change to Microsoft.eShopWeb.ApplicationCore.Entities can break Microsoft.eShopWeb.Web.Pages.Basket, while a change to Microsoft.eShopWeb.Web.Pages.Basket can't break Microsoft.eShopWeb.ApplicationCore.Entities.
- Position
- Below the diagonal: Microsoft.eShopWeb.Web.Pages.Basket uses a module listed above it, which is the healthy direction.
33→16 Microsoft.eShopWeb.Web.Pages.Basket uses Microsoft.eShopWeb.Infrastructure.Identity✕
- Connections
- 1 pair of types, where a type in Microsoft.eShopWeb.Web.Pages.Basket uses a type in Microsoft.eShopWeb.Infrastructure.Identity.
- The types involved
Microsoft.eShopWeb.Web.Pages.Basket.CheckoutModel→Microsoft.eShopWeb.Infrastructure.Identity.ApplicationUser
- Direction
- Microsoft.eShopWeb.Web.Pages.Basket uses Microsoft.eShopWeb.Infrastructure.Identity, so a change to Microsoft.eShopWeb.Infrastructure.Identity can break Microsoft.eShopWeb.Web.Pages.Basket, while a change to Microsoft.eShopWeb.Web.Pages.Basket can't break Microsoft.eShopWeb.Infrastructure.Identity.
- Position
- Below the diagonal: Microsoft.eShopWeb.Web.Pages.Basket uses a module listed above it, which is the healthy direction.
33→39 Microsoft.eShopWeb.Web.Pages.Basket uses Microsoft.eShopWeb.Web.Interfaces part of a loop✕
- Connections
- 2 pairs of types, where a type in Microsoft.eShopWeb.Web.Pages.Basket uses a type in Microsoft.eShopWeb.Web.Interfaces.
- The types involved
Microsoft.eShopWeb.Web.Pages.Basket.CheckoutModel→Microsoft.eShopWeb.Web.Interfaces.IBasketViewModelServiceMicrosoft.eShopWeb.Web.Pages.Basket.IndexModel→Microsoft.eShopWeb.Web.Interfaces.IBasketViewModelService
- Direction
- Microsoft.eShopWeb.Web.Pages.Basket uses Microsoft.eShopWeb.Web.Interfaces, so a change to Microsoft.eShopWeb.Web.Interfaces can break Microsoft.eShopWeb.Web.Pages.Basket, while a change to Microsoft.eShopWeb.Web.Pages.Basket can't break Microsoft.eShopWeb.Web.Interfaces.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
34→5 BlazorAdmin.Pages.CatalogItemPage uses BlazorShared.Models✕
- Connections
- 3 pairs of types, where a type in BlazorAdmin.Pages.CatalogItemPage uses a type in BlazorShared.Models.
- The types involved
BlazorAdmin.Pages.CatalogItemPage.List→BlazorShared.Models.CatalogBrandBlazorAdmin.Pages.CatalogItemPage.List→BlazorShared.Models.CatalogItemBlazorAdmin.Pages.CatalogItemPage.List→BlazorShared.Models.CatalogType
- Direction
- BlazorAdmin.Pages.CatalogItemPage uses BlazorShared.Models, so a change to BlazorShared.Models can break BlazorAdmin.Pages.CatalogItemPage, while a change to BlazorAdmin.Pages.CatalogItemPage can't break BlazorShared.Models.
- Position
- Below the diagonal: BlazorAdmin.Pages.CatalogItemPage uses a module listed above it, which is the healthy direction.
34→9 BlazorAdmin.Pages.CatalogItemPage uses BlazorShared.Interfaces✕
- Connections
- 2 pairs of types, where a type in BlazorAdmin.Pages.CatalogItemPage uses a type in BlazorShared.Interfaces.
- The types involved
BlazorAdmin.Pages.CatalogItemPage.List→BlazorShared.Interfaces.ICatalogItemServiceBlazorAdmin.Pages.CatalogItemPage.List→BlazorShared.Interfaces.ICatalogLookupDataService
- Direction
- BlazorAdmin.Pages.CatalogItemPage uses BlazorShared.Interfaces, so a change to BlazorShared.Interfaces can break BlazorAdmin.Pages.CatalogItemPage, while a change to BlazorAdmin.Pages.CatalogItemPage can't break BlazorShared.Interfaces.
- Position
- Below the diagonal: BlazorAdmin.Pages.CatalogItemPage uses a module listed above it, which is the healthy direction.
34→19 BlazorAdmin.Pages.CatalogItemPage uses BlazorAdmin.Helpers✕
- Connections
- 1 pair of types, where a type in BlazorAdmin.Pages.CatalogItemPage uses a type in BlazorAdmin.Helpers.
- The types involved
BlazorAdmin.Pages.CatalogItemPage.List→BlazorAdmin.Helpers.BlazorComponent
- Direction
- BlazorAdmin.Pages.CatalogItemPage uses BlazorAdmin.Helpers, so a change to BlazorAdmin.Helpers can break BlazorAdmin.Pages.CatalogItemPage, while a change to BlazorAdmin.Pages.CatalogItemPage can't break BlazorAdmin.Helpers.
- Position
- Below the diagonal: BlazorAdmin.Pages.CatalogItemPage uses a module listed above it, which is the healthy direction.
35→4 BlazorAdmin.Pages.RolePage uses BlazorAdmin.Interfaces✕
- Connections
- 1 pair of types, where a type in BlazorAdmin.Pages.RolePage uses a type in BlazorAdmin.Interfaces.
- The types involved
BlazorAdmin.Pages.RolePage.List→BlazorAdmin.Interfaces.IRoleManagementService
- Direction
- BlazorAdmin.Pages.RolePage uses BlazorAdmin.Interfaces, so a change to BlazorAdmin.Interfaces can break BlazorAdmin.Pages.RolePage, while a change to BlazorAdmin.Pages.RolePage can't break BlazorAdmin.Interfaces.
- Position
- Below the diagonal: BlazorAdmin.Pages.RolePage uses a module listed above it, which is the healthy direction.
35→19 BlazorAdmin.Pages.RolePage uses BlazorAdmin.Helpers✕
- Connections
- 1 pair of types, where a type in BlazorAdmin.Pages.RolePage uses a type in BlazorAdmin.Helpers.
- The types involved
BlazorAdmin.Pages.RolePage.List→BlazorAdmin.Helpers.BlazorComponent
- Direction
- BlazorAdmin.Pages.RolePage uses BlazorAdmin.Helpers, so a change to BlazorAdmin.Helpers can break BlazorAdmin.Pages.RolePage, while a change to BlazorAdmin.Pages.RolePage can't break BlazorAdmin.Helpers.
- Position
- Below the diagonal: BlazorAdmin.Pages.RolePage uses a module listed above it, which is the healthy direction.
36→1 BlazorAdmin.Pages.UserPage uses BlazorAdmin.Models✕
- Connections
- 1 pair of types, where a type in BlazorAdmin.Pages.UserPage uses a type in BlazorAdmin.Models.
- The types involved
BlazorAdmin.Pages.UserPage.List→BlazorAdmin.Models.User
- Direction
- BlazorAdmin.Pages.UserPage uses BlazorAdmin.Models, so a change to BlazorAdmin.Models can break BlazorAdmin.Pages.UserPage, while a change to BlazorAdmin.Pages.UserPage can't break BlazorAdmin.Models.
- Position
- Below the diagonal: BlazorAdmin.Pages.UserPage uses a module listed above it, which is the healthy direction.
36→4 BlazorAdmin.Pages.UserPage uses BlazorAdmin.Interfaces✕
- Connections
- 1 pair of types, where a type in BlazorAdmin.Pages.UserPage uses a type in BlazorAdmin.Interfaces.
- The types involved
BlazorAdmin.Pages.UserPage.List→BlazorAdmin.Interfaces.IUserManagementService
- Direction
- BlazorAdmin.Pages.UserPage uses BlazorAdmin.Interfaces, so a change to BlazorAdmin.Interfaces can break BlazorAdmin.Pages.UserPage, while a change to BlazorAdmin.Pages.UserPage can't break BlazorAdmin.Interfaces.
- Position
- Below the diagonal: BlazorAdmin.Pages.UserPage uses a module listed above it, which is the healthy direction.
36→19 BlazorAdmin.Pages.UserPage uses BlazorAdmin.Helpers✕
- Connections
- 1 pair of types, where a type in BlazorAdmin.Pages.UserPage uses a type in BlazorAdmin.Helpers.
- The types involved
BlazorAdmin.Pages.UserPage.List→BlazorAdmin.Helpers.BlazorComponent
- Direction
- BlazorAdmin.Pages.UserPage uses BlazorAdmin.Helpers, so a change to BlazorAdmin.Helpers can break BlazorAdmin.Pages.UserPage, while a change to BlazorAdmin.Pages.UserPage can't break BlazorAdmin.Helpers.
- Position
- Below the diagonal: BlazorAdmin.Pages.UserPage uses a module listed above it, which is the healthy direction.
37→11 Microsoft.eShopWeb.Infrastructure.Data.Queries uses Microsoft.eShopWeb.ApplicationCore.Interfaces✕
- Connections
- 1 pair of types, where a type in Microsoft.eShopWeb.Infrastructure.Data.Queries uses a type in Microsoft.eShopWeb.ApplicationCore.Interfaces.
- The types involved
Microsoft.eShopWeb.Infrastructure.Data.Queries.BasketQueryService→Microsoft.eShopWeb.ApplicationCore.Interfaces.IBasketQueryService
- Direction
- Microsoft.eShopWeb.Infrastructure.Data.Queries uses Microsoft.eShopWeb.ApplicationCore.Interfaces, so a change to Microsoft.eShopWeb.ApplicationCore.Interfaces can break Microsoft.eShopWeb.Infrastructure.Data.Queries, while a change to Microsoft.eShopWeb.Infrastructure.Data.Queries can't break Microsoft.eShopWeb.ApplicationCore.Interfaces.
- Position
- Below the diagonal: Microsoft.eShopWeb.Infrastructure.Data.Queries uses a module listed above it, which is the healthy direction.
37→22 Microsoft.eShopWeb.Infrastructure.Data.Queries uses Microsoft.eShopWeb.Infrastructure.Data✕
- Connections
- 1 pair of types, where a type in Microsoft.eShopWeb.Infrastructure.Data.Queries uses a type in Microsoft.eShopWeb.Infrastructure.Data.
- The types involved
Microsoft.eShopWeb.Infrastructure.Data.Queries.BasketQueryService→Microsoft.eShopWeb.Infrastructure.Data.CatalogContext
- Direction
- Microsoft.eShopWeb.Infrastructure.Data.Queries uses Microsoft.eShopWeb.Infrastructure.Data, so a change to Microsoft.eShopWeb.Infrastructure.Data can break Microsoft.eShopWeb.Infrastructure.Data.Queries, while a change to Microsoft.eShopWeb.Infrastructure.Data.Queries can't break Microsoft.eShopWeb.Infrastructure.Data.
- Position
- Below the diagonal: Microsoft.eShopWeb.Infrastructure.Data.Queries uses a module listed above it, which is the healthy direction.
38→2 Microsoft.eShopWeb.PublicApi.Extensions uses BlazorShared✕
- Connections
- 1 pair of types, where a type in Microsoft.eShopWeb.PublicApi.Extensions uses a type in BlazorShared.
- The types involved
Microsoft.eShopWeb.PublicApi.Extensions.ServiceCollectionExtensions→BlazorShared.BaseUrlConfiguration
- Direction
- Microsoft.eShopWeb.PublicApi.Extensions uses BlazorShared, so a change to BlazorShared can break Microsoft.eShopWeb.PublicApi.Extensions, while a change to Microsoft.eShopWeb.PublicApi.Extensions can't break BlazorShared.
- Position
- Below the diagonal: Microsoft.eShopWeb.PublicApi.Extensions uses a module listed above it, which is the healthy direction.
38→16 Microsoft.eShopWeb.PublicApi.Extensions uses Microsoft.eShopWeb.Infrastructure.Identity✕
- Connections
- 1 pair of types, where a type in Microsoft.eShopWeb.PublicApi.Extensions uses a type in Microsoft.eShopWeb.Infrastructure.Identity.
- The types involved
Microsoft.eShopWeb.PublicApi.Extensions.ApplicationUserExtensions→Microsoft.eShopWeb.Infrastructure.Identity.ApplicationUser
- Direction
- Microsoft.eShopWeb.PublicApi.Extensions uses Microsoft.eShopWeb.Infrastructure.Identity, so a change to Microsoft.eShopWeb.Infrastructure.Identity can break Microsoft.eShopWeb.PublicApi.Extensions, while a change to Microsoft.eShopWeb.PublicApi.Extensions can't break Microsoft.eShopWeb.Infrastructure.Identity.
- Position
- Below the diagonal: Microsoft.eShopWeb.PublicApi.Extensions uses a module listed above it, which is the healthy direction.
38→30 Microsoft.eShopWeb.PublicApi.Extensions uses Microsoft.eShopWeb.PublicApi.UserManagementEndpoints✕
- Connections
- 1 pair of types, where a type in Microsoft.eShopWeb.PublicApi.Extensions uses a type in Microsoft.eShopWeb.PublicApi.UserManagementEndpoints.
- The types involved
Microsoft.eShopWeb.PublicApi.Extensions.ApplicationUserExtensions→Microsoft.eShopWeb.PublicApi.UserManagementEndpoints.UserDto
- Direction
- Microsoft.eShopWeb.PublicApi.Extensions uses Microsoft.eShopWeb.PublicApi.UserManagementEndpoints, so a change to Microsoft.eShopWeb.PublicApi.UserManagementEndpoints can break Microsoft.eShopWeb.PublicApi.Extensions, while a change to Microsoft.eShopWeb.PublicApi.Extensions can't break Microsoft.eShopWeb.PublicApi.UserManagementEndpoints.
- Position
- Below the diagonal: Microsoft.eShopWeb.PublicApi.Extensions uses a module listed above it, which is the healthy direction.
39→6 Microsoft.eShopWeb.Web.Interfaces uses Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate✕
- Connections
- 1 pair of types, where a type in Microsoft.eShopWeb.Web.Interfaces uses a type in Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate.
- The types involved
Microsoft.eShopWeb.Web.Interfaces.IBasketViewModelService→Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate.Basket
- Direction
- Microsoft.eShopWeb.Web.Interfaces uses Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate, so a change to Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate can break Microsoft.eShopWeb.Web.Interfaces, while a change to Microsoft.eShopWeb.Web.Interfaces can't break Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate.
- Position
- Below the diagonal: Microsoft.eShopWeb.Web.Interfaces uses a module listed above it, which is the healthy direction.
39→12 Microsoft.eShopWeb.Web.Interfaces uses Microsoft.eShopWeb.Web.ViewModels✕
- Connections
- 1 pair of types, where a type in Microsoft.eShopWeb.Web.Interfaces uses a type in Microsoft.eShopWeb.Web.ViewModels.
- The types involved
Microsoft.eShopWeb.Web.Interfaces.ICatalogItemViewModelService→Microsoft.eShopWeb.Web.ViewModels.CatalogItemViewModel
- Direction
- Microsoft.eShopWeb.Web.Interfaces uses Microsoft.eShopWeb.Web.ViewModels, so a change to Microsoft.eShopWeb.Web.ViewModels can break Microsoft.eShopWeb.Web.Interfaces, while a change to Microsoft.eShopWeb.Web.Interfaces can't break Microsoft.eShopWeb.Web.ViewModels.
- Position
- Below the diagonal: Microsoft.eShopWeb.Web.Interfaces uses a module listed above it, which is the healthy direction.
39→33 Microsoft.eShopWeb.Web.Interfaces uses Microsoft.eShopWeb.Web.Pages.Basket✕
- Connections
- 1 pair of types, where a type in Microsoft.eShopWeb.Web.Interfaces uses a type in Microsoft.eShopWeb.Web.Pages.Basket.
- The types involved
Microsoft.eShopWeb.Web.Interfaces.IBasketViewModelService→Microsoft.eShopWeb.Web.Pages.Basket.BasketViewModel
- Direction
- Microsoft.eShopWeb.Web.Interfaces uses Microsoft.eShopWeb.Web.Pages.Basket, so a change to Microsoft.eShopWeb.Web.Pages.Basket can break Microsoft.eShopWeb.Web.Interfaces, while a change to Microsoft.eShopWeb.Web.Interfaces can't break Microsoft.eShopWeb.Web.Pages.Basket.
- Position
- Below the diagonal: Microsoft.eShopWeb.Web.Interfaces uses a module listed above it, which is the healthy direction.
40→6 Microsoft.eShopWeb.Web.Services uses Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate✕
- Connections
- 2 pairs of types, where a type in Microsoft.eShopWeb.Web.Services uses a type in Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate.
- The types involved
Microsoft.eShopWeb.Web.Services.BasketViewModelService→Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate.BasketMicrosoft.eShopWeb.Web.Services.BasketViewModelService→Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate.BasketItem
- Direction
- Microsoft.eShopWeb.Web.Services uses Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate, so a change to Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate can break Microsoft.eShopWeb.Web.Services, while a change to Microsoft.eShopWeb.Web.Services can't break Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate.
- Position
- Below the diagonal: Microsoft.eShopWeb.Web.Services uses a module listed above it, which is the healthy direction.
40→11 Microsoft.eShopWeb.Web.Services uses Microsoft.eShopWeb.ApplicationCore.Interfaces✕
- Connections
- 7 pairs of types, where a type in Microsoft.eShopWeb.Web.Services uses a type in Microsoft.eShopWeb.ApplicationCore.Interfaces.
- The types involved
Microsoft.eShopWeb.Web.Services.BasketViewModelService→Microsoft.eShopWeb.ApplicationCore.Interfaces.IBasketQueryServiceMicrosoft.eShopWeb.Web.Services.BasketViewModelService→Microsoft.eShopWeb.ApplicationCore.Interfaces.IRepositoryMicrosoft.eShopWeb.Web.Services.BasketViewModelService→Microsoft.eShopWeb.ApplicationCore.Interfaces.IUriComposerMicrosoft.eShopWeb.Web.Services.CatalogItemViewModelService→Microsoft.eShopWeb.ApplicationCore.Interfaces.IRepositoryMicrosoft.eShopWeb.Web.Services.CatalogViewModelService→Microsoft.eShopWeb.ApplicationCore.Interfaces.IRepositoryMicrosoft.eShopWeb.Web.Services.CatalogViewModelService→Microsoft.eShopWeb.ApplicationCore.Interfaces.IUriComposerMicrosoft.eShopWeb.Web.Services.EmailSenderExtensions→Microsoft.eShopWeb.ApplicationCore.Interfaces.IEmailSender
- Direction
- Microsoft.eShopWeb.Web.Services uses Microsoft.eShopWeb.ApplicationCore.Interfaces, so a change to Microsoft.eShopWeb.ApplicationCore.Interfaces can break Microsoft.eShopWeb.Web.Services, while a change to Microsoft.eShopWeb.Web.Services can't break Microsoft.eShopWeb.ApplicationCore.Interfaces.
- Position
- Below the diagonal: Microsoft.eShopWeb.Web.Services uses a module listed above it, which is the healthy direction.
40→12 Microsoft.eShopWeb.Web.Services uses Microsoft.eShopWeb.Web.ViewModels✕
- Connections
- 4 pairs of types, where a type in Microsoft.eShopWeb.Web.Services uses a type in Microsoft.eShopWeb.Web.ViewModels.
- The types involved
Microsoft.eShopWeb.Web.Services.CachedCatalogViewModelService→Microsoft.eShopWeb.Web.ViewModels.CatalogIndexViewModelMicrosoft.eShopWeb.Web.Services.CatalogItemViewModelService→Microsoft.eShopWeb.Web.ViewModels.CatalogItemViewModelMicrosoft.eShopWeb.Web.Services.CatalogViewModelService→Microsoft.eShopWeb.Web.ViewModels.CatalogIndexViewModelMicrosoft.eShopWeb.Web.Services.ICatalogViewModelService→Microsoft.eShopWeb.Web.ViewModels.CatalogIndexViewModel
- Direction
- Microsoft.eShopWeb.Web.Services uses Microsoft.eShopWeb.Web.ViewModels, so a change to Microsoft.eShopWeb.Web.ViewModels can break Microsoft.eShopWeb.Web.Services, while a change to Microsoft.eShopWeb.Web.Services can't break Microsoft.eShopWeb.Web.ViewModels.
- Position
- Below the diagonal: Microsoft.eShopWeb.Web.Services uses a module listed above it, which is the healthy direction.
40→14 Microsoft.eShopWeb.Web.Services uses Microsoft.eShopWeb.ApplicationCore.Entities✕
- Connections
- 5 pairs of types, where a type in Microsoft.eShopWeb.Web.Services uses a type in Microsoft.eShopWeb.ApplicationCore.Entities.
- The types involved
Microsoft.eShopWeb.Web.Services.BasketViewModelService→Microsoft.eShopWeb.ApplicationCore.Entities.CatalogItemMicrosoft.eShopWeb.Web.Services.CatalogItemViewModelService→Microsoft.eShopWeb.ApplicationCore.Entities.CatalogItemMicrosoft.eShopWeb.Web.Services.CatalogViewModelService→Microsoft.eShopWeb.ApplicationCore.Entities.CatalogBrandMicrosoft.eShopWeb.Web.Services.CatalogViewModelService→Microsoft.eShopWeb.ApplicationCore.Entities.CatalogItemMicrosoft.eShopWeb.Web.Services.CatalogViewModelService→Microsoft.eShopWeb.ApplicationCore.Entities.CatalogType
- Direction
- Microsoft.eShopWeb.Web.Services uses Microsoft.eShopWeb.ApplicationCore.Entities, so a change to Microsoft.eShopWeb.ApplicationCore.Entities can break Microsoft.eShopWeb.Web.Services, while a change to Microsoft.eShopWeb.Web.Services can't break Microsoft.eShopWeb.ApplicationCore.Entities.
- Position
- Below the diagonal: Microsoft.eShopWeb.Web.Services uses a module listed above it, which is the healthy direction.
40→33 Microsoft.eShopWeb.Web.Services uses Microsoft.eShopWeb.Web.Pages.Basket✕
- Connections
- 2 pairs of types, where a type in Microsoft.eShopWeb.Web.Services uses a type in Microsoft.eShopWeb.Web.Pages.Basket.
- The types involved
Microsoft.eShopWeb.Web.Services.BasketViewModelService→Microsoft.eShopWeb.Web.Pages.Basket.BasketItemViewModelMicrosoft.eShopWeb.Web.Services.BasketViewModelService→Microsoft.eShopWeb.Web.Pages.Basket.BasketViewModel
- Direction
- Microsoft.eShopWeb.Web.Services uses Microsoft.eShopWeb.Web.Pages.Basket, so a change to Microsoft.eShopWeb.Web.Pages.Basket can break Microsoft.eShopWeb.Web.Services, while a change to Microsoft.eShopWeb.Web.Services can't break Microsoft.eShopWeb.Web.Pages.Basket.
- Position
- Below the diagonal: Microsoft.eShopWeb.Web.Services uses a module listed above it, which is the healthy direction.
40→39 Microsoft.eShopWeb.Web.Services uses Microsoft.eShopWeb.Web.Interfaces✕
- Connections
- 2 pairs of types, where a type in Microsoft.eShopWeb.Web.Services uses a type in Microsoft.eShopWeb.Web.Interfaces.
- The types involved
Microsoft.eShopWeb.Web.Services.BasketViewModelService→Microsoft.eShopWeb.Web.Interfaces.IBasketViewModelServiceMicrosoft.eShopWeb.Web.Services.CatalogItemViewModelService→Microsoft.eShopWeb.Web.Interfaces.ICatalogItemViewModelService
- Direction
- Microsoft.eShopWeb.Web.Services uses Microsoft.eShopWeb.Web.Interfaces, so a change to Microsoft.eShopWeb.Web.Interfaces can break Microsoft.eShopWeb.Web.Services, while a change to Microsoft.eShopWeb.Web.Services can't break Microsoft.eShopWeb.Web.Interfaces.
- Position
- Below the diagonal: Microsoft.eShopWeb.Web.Services uses a module listed above it, which is the healthy direction.
At a glance — Code Health
At a glance — Architecture
At a glance — Maturity
At a glance — Readiness
At a glance — Security
At a glance — Domain Modelling
At a glance — Accessibility
At a glance — Performance
Security & Compliance — OWASP Top-10 mapping
| OWASP category | Findings | Severity |
|---|---|---|
| A02:2025 — Security Misconfiguration | 39 | High / Critical |
| A05:2025 — Injection | 22 | High / Critical |
| A07:2025 — Authentication Failures | 13 | High / Critical |
| A03:2025 — Software Supply Chain Failures | 12 | High / Critical |
Roadmap
First, ensure all media elements have appropriate text alternatives and make custom controls fully keyboard-operable with valid anchor links. Next, integrate accessibility checks into the test suite and CI pipeline to prevent future regressions. Finally, correct documentation inaccuracies regarding the project structure and resolve the identified secret leaks in configuration files.
| Do this | Helps | Effort | Dimension |
|---|---|---|---|
| Add a text alternative — alt on images (alt="" for purely decorative ones), a title or aria-label on meaningful svg, an aria-label or inner fallback content on canvas, and a captions <track> on video. | +5.2 pts | Medium | Text alternatives |
| Make custom controls keyboard-operable (role + tabindex + key handler), drop positive tabindex, and give anchors a real href. | +5.0 pts | Medium | Keyboard semantics |
| Resolve the 7 Leaked secret finding(s) in REDACTED Scanning — start with REDACTED (4), REDACTED, REDACTED. | +2.0 pts | Low | REDACTED Scanning |
| Resolve the 1 No context/problem and no consequences/trade-offs; only implementation… finding(s) in ADR Quality — start with 2025-04-25-just-the-docs-theme.md. | +1.3 pts | Low | ADR Quality |
| Resolve the 1 The document is a boilerplate request with no context/problem and no… finding(s) in ADR Quality — start with 2025-04-24-document-decisions.md. | +1.3 pts | Low | ADR Quality |
| Enforce accessibility in the test suite you already have: assert the accessibility invariants over the HTML your app renders — parse the rendered output in an existing test, or drive a real browser from one — and gate that test in CI so a regression blocks the merge. | +2.5 pts | Medium | A11y enforcement |
| Resolve the 7 Orphaned file finding(s) in Knowledge Freshness — start with HttpService.cs, Extensions.cs, Login.cshtml.cs. | +1.2 pts | Low | Knowledge Freshness |
| Reconcile the README with reality: README advertises a microservices architecture, but the repo is a single project with no service manifests; docs/getting-started-for-beginners.md names `Startup.cs`, but no file or folder `Startup.cs` exists; docs/walkthroughs/deploy-to-azure-app-service-from-azure-portal.md names `eShopOnWeb.sln`, but no file or folder `eShopOnWeb.sln` exists; docs/walkthroughs/deploying-windows-container-to-azure.md documents the environment variable `DS1_V2`, but no code, script or configuration file names it. | +2.0 pts | Medium | Documentation accuracy |
File quality
| File | Score | Band | Worst signal |
|---|---|---|---|
| REDACTED | 1.4 | Slop | Static Analysis (SAST): High: REDACTED |
| REDACTED | 1.6 | Slop | REDACTED Scanning: Leaked secret: REDACTED |
| REDACTED | 1.6 | Slop | REDACTED Scanning: Leaked secret: REDACTED |
| REDACTED | 3.0 | Mixed | Static Analysis (SAST): High: REDACTED |
| REDACTED | 3.0 | Mixed | Static Analysis (SAST): High: REDACTED |
| REDACTED | 3.4 | Mixed | IaC & Container Security: High IaC: REDACTED |
| REDACTED | 4.1 | Mixed | IaC & Container Security: High IaC: REDACTED |
| REDACTED | 5.1 | Mixed | REDACTED Scanning: Leaked secret: REDACTED |
| REDACTED | 5.1 | Mixed | Dependency Vulnerabilities: High CVE: REDACTED |
| REDACTED | 5.8 | Mixed | IaC & Container Security: Medium IaC: REDACTED |
| REDACTED | 5.8 | Mixed | IaC & Container Security: Medium IaC: REDACTED |
| REDACTED | 6.1 | Near-clean | IaC & Container Security: Medium IaC: REDACTED |
| REDACTED | 6.3 | Near-clean | Static Analysis (SAST): Medium: REDACTED |
| src/Web/Areas/Identity/Pages/Account/Logout.cshtml.cs | 6.7 | Near-clean | Explicit Debt: TodoComment |
| REDACTED | 6.9 | Near-clean | Static Analysis (SAST): Medium: REDACTED |
| REDACTED | 6.9 | Near-clean | IaC & Container Security: Medium IaC: REDACTED |
| src/BlazorAdmin/Services/HttpService.cs | 7.2 | Near-clean | Code Duplication: Members sharing a duplicated core (4 members, 50+ identical tokens) |
| REDACTED | 7.2 | Near-clean | REDACTED Scanning: Leaked secret: REDACTED |
| REDACTED | 7.2 | Near-clean | REDACTED Scanning: Leaked secret: REDACTED |
| REDACTED | 7.2 | Near-clean | Secrets (history): REDACTED: REDACTED |
How the grades work
A definite problem that already costs you something and drags the score down: a missing authorisation check, a dependency with a known exploit, a build that does not reproduce. Failure here tends to cause failures elsewhere.
Likely wrong, but not failing yet. It degrades the codebase over a longer horizon and can cause failures elsewhere — not urgent this week, not something to carry for two years either.
Recorded, with no effect on how the codebase functions. Present so the survey is complete, not because it needs doing.
Something this survey could not settle from the outside, and which could be critical or serious. Either a control was required and no positive evidence of it exists in the repository — a backup job that nothing shows was ever restored from proves nothing about restores — or our own analysis could not run over that part of the tree. This is not a clean result. These are excluded from the score rather than awarded a pass, so the number on the cover neither rewards nor penalises them: if you act on this survey without resolving them, you carry that risk yourself. Each one is named under Limitations.
Methodology & how to trust this report
Watchdog is a deep, periodic assessment — run each sprint, monthly, or quarterly, taking the time to go wider and deeper than a quick check and surfacing in one coherent report what you'd otherwise piece together from a dozen separate tools. It scores deterministically: the same commit yields the same score, every run. 89 of 94 evaluated dimensions are computed purely by tools and static analysis (confidence 1.0); 5 documentation/naming judgement(s) are LLM-assisted and labelled advisory. Overall confidence is 0.9 — the weighted average across measured dimensions; it falls as more of the score leans on LLM-assisted judgement and rises when it's fully tool-backed.
What we checked — 94 dimensions across the health lenses
- Can you open the finding? Real findings cite a repo-relative file and line you can open at the cited line — never an absolute scratch path. Here, 280 of 300 do; the remainder are repo-wide signals — a dimension-level measurement, not a single line.
- Is there a tool behind the number? Every score below names the method that produced it — Roslyn, git, a scanner, or (for a handful of documentation/naming dimensions) an LLM labelled sampled · advisory — not a narrative.
- Does re-running give the same result? Run it again on the same commit and the score — and this report, byte for byte — is identical. A report whose numbers move between runs is describing the run, not the code.
Tools & methods
| Method | Backs | Version | Evaluator |
|---|---|---|---|
| Roslyn static analysis | Complexity, cohesion, coupling, dead code, API surface, layering | 5.3.0 | ✓ deterministic |
| Native secret scanner | Hardcoded secrets / credentials | 1.0.0 | ✓ deterministic |
| Watchdog duplication detector (in-process) | Code duplication | 1.0.0 | ✓ deterministic |
| Coverage (coverlet / dotnet-coverage) | Line & branch coverage | 10.0.400 | ✓ deterministic |
| NuGet / dotnet | Outdated, vulnerable & deprecated dependencies | 10.0.400 | ✓ deterministic |
| git / LibGit2Sharp | Churn hotspots, knowledge concentration, history | 2.43.0 · 0.31.0 | ✓ deterministic |
| gitleaks · semgrep · trivy · checkov | Secrets in history, SAST, CVEs, IaC & container, PII / GDPR | 1.86.0 · 0.69.3 · 3.2.533 | ✓ deterministic |
| LLM (sampled · advisory) | Documentation quality, ADR conformance, naming — sampled over a bounded sample; advisory, never a deterministic measurement | Local LLM | ◐ LLM · sampled · advisory |
Run transparency — what happened this run
- D11 Test Reliability — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. Test reliability not scored — the test tier(s) ran but surfaced none of this repository's 102 test method(s) to the runner, so flakiness couldn't be exercised. This is an analysis-environment limitation, not a finding about the tests.
- D12 Dependency Hygiene — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. `dotnet list package` did not return usable output (restore or query failed); no outdated/vulnerable/deprecated data to assess. The tool said: `dotnet list package` exited 1 with no output.
- D14 License Compliance — measured, with a gap in what it reached — Watchdog measured this, but not all of it. What it did not reach is a gap on our side — a collector, parser or image we have not built yet — so the numbers on that dimension cover less than the repository, and the part left out is not evidence that it would have passed. This repository declares a Ruby Gemfile/Gemfile.lock or .gemspec (Bundler/RubyGems), but the licence verdict published here was taken over its NuGet package dependencies. Nothing was read about its Bundler dependencies' licensing in either direction, and a clean score on this card must not be read as covering them.
- D17 Explicit Debt — measured, with a gap in what it reached — Watchdog measured this, but not all of it. What it did not reach is a gap on our side — a collector, parser or image we have not built yet — so the numbers on that dimension cover less than the repository, and the part left out is not evidence that it would have passed. The C# workspace loaded this repository's projects but reported a load failure, and the dead-code reference search is unreliable over a graph that did not load cleanly, so it was skipped. The other debt markers on this row were read; dead symbols were not, and their absence from the score is not a finding that the code has none. First load diagnostic: Failure: Cannot open project 'docker-compose.dcproj' because the file extension '.dcproj' is not associated with a language.
- D18 Solution Shape — measured, with a gap in what it reached — Watchdog measured this, but not all of it. What it did not reach is a gap on our side — a collector, parser or image we have not built yet — so the numbers on that dimension cover less than the repository, and the part left out is not evidence that it would have passed. `dotnet build` reported 6 error(s), and the diagnostics it printed were: LIB002: The "jquery@3.6.3" library could not be resolved by the "cdnjs" provider; LIB002: The "twitter-bootstrap@3.4.1" library could not be resolved by the "cdnjs" provider; LIB002: The "jquery-validation-unobtrusive@4.0.0" library could not be resolved by the "cdnjs" provider; LIB002: The "jquery-validate@1.19.5" library could not be resolved by the "cdnjs" provider; LIB002: The "toastr.js@2.1.4" library could not be resolved by the "cdnjs" provider. None of them is a .NET compiler diagnostic, which is the only signal this check reads as "the code does not compile", so the failure is recorded as a build-environment gap rather than a code defect. The usual causes are a project that targets a platform this run cannot build (a Windows-only target framework on a Linux worker) or a build step that shells out to a tool the image does not carry. Solution Shape is scored on structure and is NOT capped. Semantic analysis is independent of this build and covers every project that loaded — but a project whose restore did not complete has no resolved references, so treat its results as absent rather than clean. ★ The reach of that test, stated so this classification can be checked rather than taken on trust: it reads the C# (CS), Visual Basic (BC) and F# (FS) compiler series, and treats SDK, NuGet-restore and MSBuild codes (NETSDK, NU, MSB) as evidence that the build did not run rather than that the code is broken — read the diagnostics named above and judge for yourself. You can widen what we reach: if this build is meant to run off its own platform, without host tooling we do not carry, the diagnostics named above are what stopped it. If it is deliberately platform-bound — a Windows-only desktop product, say — there is nothing to do here: the note records our reach, not a defect in your build.
- D22 Internal API Consistency — not measured this run — This is a true statement about the repository that carries nothing for its owner to act on, so it is reported here rather than as a defect in their code. The loaded project set declares no packable project and no `.Contracts` project, so there is no intentionally-exposed surface for API consistency to be judged over.
- D28 Secrets (history) — measured, with a gap in what it reached — Watchdog measured this, but not all of it. What it did not reach is a gap on our side — a collector, parser or image we have not built yet — so the numbers on that dimension cover less than the repository, and the part left out is not evidence that it would have passed. D28's config-credential rule (WD-SECRET-0002) parses each committed `.json` config as a document and reads credential-named values; `src/Web/compilerconfig.json`, `REDACTED` did not parse (JSON5, a template, several concatenated documents), so a credential bound there is UNMEASURED by that rule. gitleaks still scanned the same files as text.
- D30 Dependency Vulnerabilities — measured, with a gap in what it reached — Watchdog measured this, but not all of it. What it did not reach is a gap on our side — a collector, parser or image we have not built yet — so the numbers on that dimension cover less than the repository, and the part left out is not evidence that it would have passed. The scanner produced no output at all, so no dependency was actually scanned. 1 of 2 declared ecosystem(s) (nuget) WERE scanned and every vulnerability they reported is included in this result; osv was not, so this dimension's score covers less than the dependency surface this repository declares, and nothing here is evidence that osv is free of known-vulnerable dependencies.
- D32 Data Compliance (PII/GDPR) — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. `src/ApplicationCore/Entities/OrderAggregate/Events/OrderCreatedEvent.cs`, `src/ApplicationCore/Entities/OrderAggregate/Handlers/OrderCreatedHandler.cs`, `src/BlazorAdmin/Services/RoleManagementService.cs`, `src/BlazorAdmin/Services/UserManagementService.cs`, `src/Infrastructure/Identity/JwtSettingsValidator.cs`, … (+26 more) produced a parse error, so every rule in this engine's `gdpr.yml` was absent there. That absence is NOT a clean result: these rules detect personal data crossing a boundary into a log sink, a URL or browser storage, and a file that was never parsed cannot report any of the three. The rest of the tree analysed normally and its rows above stand; only these files are unaccounted for. You can widen what we reach: fix the syntax error (or exclude the file deliberately) and re-scan to cover it.
- D39 IL Efficiency — not measured this run — This is a true statement about the repository that carries nothing for its owner to act on, so it is reported here rather than as a defect in their code. `dotnet build` exited 1 with a compiler/MSBuild diagnostic, so there were no assemblies to read IL from. The build itself is D18's row, with the ask; nothing further is charged here.
- D43 Malicious Dependencies — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. Osv: the scanner produced no output at all, so no dependency was actually scanned. 'osv-scanner' exited 128 and produced no findings, and that exit code has no documented repo-side meaning — so this run measured nothing, and nothing here is a statement about the repository.
- AXR1 Runtime accessibility — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. Render strategy: boot via AspireAppHost (REDACTED). the Aspire AppHost did not expose a crawlable HTTP endpoint in time (or only the dashboard) — no runtime evidence.
- X2 Cancellation propagation — measured, with a gap in what it reached — Watchdog measured this, but not all of it. What it did not reach is a gap on our side — a collector, parser or image we have not built yet — so the numbers on that dimension cover less than the repository, and the part left out is not evidence that it would have passed. 68 further occurrence(s) are not listed individually; the score already reflects all 108.
Limitations & what we did not check
Watchdog assesses the repository exactly as committed, and only the repository. By design it does not reach outside the source tree: the live cloud account, the running CI/CD pipeline, the host's branch-protection and approval rules, the production configuration, or a restore actually exercised against a backup are all out of scope. That boundary is a feature, not a gap — a repo-relative, deterministic scan re-runs identically on any commit and every finding opens at a real file and line, where a live audit can neither be reproduced nor traced. The visible consequence is that controls which leave no in-repo evidence are reported as "not evidenced" and excluded from the score rather than awarded a number a static scan cannot justify.
Per-dimension blind spots
- D1 Cyclomatic Complexity: Cyclomatic complexity counts branches statically — it cannot tell an essential decision tree from accidental tangle, nor see complexity that lives in data or configuration (large switch-case token tables, DSL lexers/parsers, data-as-code rule tables) rather than control flow: a tokenizer's many single-character cases read as high complexity though each branch is trivial.
- D2 Cognitive Complexity: Cognitive-complexity heuristics approximate how hard code is to follow; genuine domain difficulty and well-named intent that eases reading are not captured.
- D3 God Classes: "God class" is sized by members and responsibilities visible in the type — a deliberately broad facade over a coherent subsystem can read the same as an accidental grab-bag. For front-end JS the file-length check is cohesion-aware (a single-responsibility module — one class/IIFE — earns a 3× threshold), but cohesion is approximated from top-level declarations, not true dependency structure.
- D4 Code Duplication: Duplication is token-similarity — an in-process token-stream comparison over sliding windows, with type-aware normalization — so it finds copy-paste, not semantic duplication expressed differently. Committed machine-written code (scaffolded migrations, designer/codegen output, protobuf/OpenAPI stubs, model snapshots) is EXCLUDED — its repetition is the tool's, not the team's — so the score reflects hand-written duplication only.
- D5 Coupling: Coupling is measured between projects/assemblies — runtime coupling through DI, reflection, messaging or shared databases is invisible to a static reference graph.
- D6 Cohesion (LCOM4): LCOM4 cohesion is syntactic — it infers connectivity from which methods touch which fields/methods by name, not from real runtime behaviour or intent.
- D7 Architectural Integrity: Layering is checked against detected/declared rules — an architecture whose boundaries live in convention or in code review, not in a rule a scanner can read, is not enforced here.
- D9 Test Distribution: The test-pyramid shape is inferred from project/folder naming and references, with a single test host bucketed per-file by its path tier and content signals — a suite that names tiers unconventionally and gives no per-file signal can still be mis-bucketed.
- D10 Test Quality: Assertion density is structural — it cannot tell a meaningful behavioural assertion from a trivial one, only that an assertion is present.
- D13 REDACTED Scanning: REDACTED detection is signature- and entropy-based on the current tree — a secret that does not match a known pattern, or one already rotated, will not be flagged (a clean scan is "nothing matched", not "no secrets exist").
- D14 License Compliance: License compatibility is checked against declared package metadata and a policy — mislabelled or missing license metadata, and obligations that depend on how you distribute, are not resolved here.
- D15 Churn × Complexity Hotspots: Churn hotspots come from git history — a freshly imported or squashed repository has no churn signal, and recent rewrites can mask a historically risky file.
- D16 Bus Factor: Bus-factor is a time-decayed model of commit attribution (who has recently, repeatedly worked a file), not comprehension — pairing, review and reading-without-committing spread knowledge it can't see; bot commits and shared accounts still distort it.
- D17 Explicit Debt: Acknowledged-debt signals (TODO/FIXME, suppressions, dead code) are textual — undocumented debt that nobody marked, and debt that lives in design rather than annotations, is invisible. Committed machine-written code (scaffolded migrations, designer/codegen output, generated stubs) is excluded — it is never the team's dead code to delete.
- D18 Solution Shape: Build integrity reflects whether the solution compiled in this environment — a build that needs a private feed, a specific SDK, or a generated file absent from the repo can read as broken when it is merely unreproducible here.
- D19 Documentation Quality: Documentation quality is judged by an LLM over a bounded sample of docs — it reads what is written, not whether the docs match the running system, and it is advisory, not a measurement. Its critique rows are drawn from a closed category vocabulary and each row means the same thing in every run, so two scans can be compared row by row; the SET that fires is still a sample, and does not repeat exactly. Measured on one frozen input, six scans at one engine SHA: 2-5 critique rows per scan, 8 distinct rows across the six, 3 of those 8 seen in only one scan. So a D19 row is evidence about the documentation, but a COUNT of D19 rows is not a quantity — never read a change in it as an improvement or a regression.
- D20 ADR Quality: ADR quality is an LLM read of the decision records present — it cannot know about decisions made and never recorded, and its verdict is sampled and advisory.
- D21 Naming Consistency: Naming quality is an LLM judgement over a bounded sample — it assesses clarity/consistency of the names it sees, not domain-correctness, and is advisory.
- D24 Comment Value: Comment value (WHY vs WHAT) is an LLM judgement over a bounded sample — it is advisory and cannot weigh a comment against the precise code change it was written to explain.
- D26 Project Cohesion: Project focus is sized from members/namespaces per project — a project that is broad by deliberate design reads the same as one that has sprawled.
- D27 Navigability: Indirection/navigability is structural — it measures hops to follow a call, not whether that indirection buys real flexibility or just ceremony.
- D28 Secrets (history): Secret-history scanning sweeps the git log for known patterns — a secret that predates the available history, or never matched a signature, is not found (clean means "nothing matched in the history we can see").
- D29 Static Analysis (SAST): SAST findings are pattern-based (semgrep) — it finds classes of bug it has rules for; logic flaws, auth/authorization gaps and issues needing runtime context are out of reach (and clean means "no rule matched").
- D30 Dependency Vulnerabilities: CVE matching depends on accurate package/version metadata and on the advisory databases — a vulnerability with no published advisory, or in code not declared as a dependency, is not seen. Coverage needs a RESOLVED graph: an unpinned requirements.txt, or a pom without a resolved build, yields partial coverage rather than a clean verdict. An ecosystem the analyzer cannot scan is reported as unmeasured, never as clean.
- D31 IaC & Container Security: IaC scanning checks Dockerfiles/Terraform/Kubernetes against best-practice rules — it cannot see the live cloud account, runtime configuration, or drift between the committed config and what is actually deployed.
- D34 Knowledge Freshness: Freshness is decayed commit RECENCY, not comprehension — code read often but rarely committed reads as orphaned, and stable code that genuinely needs no changes is penalised the same as forgotten code; bot/squash commits distort it like the bus factor.
- D35 Change Coupling: Change coupling is co-change in COMMITS — files split across separate commits, or coupled only through a shared config/build step, read as uncoupled, and a sweeping commit (rename/format) is excluded so it doesn't couple everything. It shows that files change together, not WHY: a high coupling can be a healthy cohesive pair as readily as a hidden leak.
- D44 Platform End-of-Life: The support table is FROZEN, so it goes out of date by losing RECALL: a release that ended support after the table was written is missed until the table is refreshed, and this dimension reading 10 is not evidence that a platform is current. Only platforms the repository DECLARES in a place this pass reads are seen — a runtime named only in a REDACTED (D31's subject), in a CI workflow (D29's), or in a file this pass does not parse (go.mod, a Gemfile ruby directive) is invisible here, which is why a repository declaring none of them abstains rather than scoring. Only frameworks with a PUBLISHED support policy are tracked: React, Flask and Express publish none, so their age cannot be judged and their absence from a report is not a statement that they are supported.
- AC1 Text alternatives: Alt-text is detected structurally — the scan sees that an alternative EXISTS, not whether it meaningfully describes the image, and decorative-vs-missing is judged by attribute shape; runtime-injected images and a non-role=img decorative svg are out of scope. This is accessibility readiness, never a WCAG conformance claim.
- AC2 Forms & labels: Label association is read from static markup — a label wired up at runtime (JS-set aria-labelledby, framework-injected ids) reads as missing, a present label says nothing about whether its text is correct. A known UI-library field component (e.g. a JSX <TextField>) is now checked conservatively — flagged only when it carries NO label/aria-label/aria-labelledby/id/name — but wrapper/context-labelled libraries (Chakra/Radix FormControl+FormLabel) aren't statically visible (possible false positive) and non-JSX lowercased components are still skipped. A click handler on a plain element is now asked for a name too (it is a control the author declared), but the subtree test that answers it is deliberately generous: any DYNAMIC text expression in the subtree counts as a name, so an icon chosen by a ternary ({cond ? <IconA/> : <IconB/>}) reads as named, and a glyph component from a library the icon-import list does not know still names its parent. A clean result is "no unlabelled control found", not a labelling proof.
- AC3 Page structure: Page structure is read from the static markup tree — landmarks, headings and lang injected at runtime aren't seen, heading ORDER is checked structurally (not against the rendered visual hierarchy), and lang/title/main fire only on full documents, never partials, and the data-table check sees header-cell presence (a <th> exists), not whether each header correctly associates with its cells. Static readiness, not conformance.
- AC4 Keyboard semantics: Keyboard semantics are inferred from markup attributes — interactivity wired purely in script, focus managed at runtime, and component-level handlers are invisible. A clean result means "no static keyboard-trap shape", not a keyboard-operability proof.
- AC5 ARIA correctness: ARIA correctness is checked against the static role/attribute shape — roles/attributes set dynamically aren't seen, a valid role says nothing about whether it matches the element's real behaviour, and required-state checks are suppressed when a JSX spread could supply them. The two-branch toggle check (a control whose state is conveyed only by which of two mutually exclusive branches renders) reads CONDITIONALS THAT ARE ATTRIBUTES — Vue v-if/v-else/v-show and Alpine x-if/x-show — so the same toggle written as a Svelte {#if} block or a JSX ternary is control flow the markup model never projects as a branch and is not seen at all.
- AC6 Visual & motion safety: Contrast and motion safety are PARTIAL by construction — literal colours (hex/rgb/hsl/named) in inline styles, in-repo <style> blocks, in-repo .css files, var() tokens, Tailwind neutral utilities and CSS-in-JS top-level declarations are read (same-rule/same-element colour+background pairs only); computed/runtime/theme colour, external-CDN stylesheets, CSS-in-JS dynamic (${…}) and nested-selector colours, cross-element pairs and image contrast stay out of reach, so a clean result is bounded by what the static CSS itself shows.
- AC7 A11y enforcement: Enforcement is scored from in-repo config/CI evidence only — an a11y gate enforced in external tooling with no in-repo trace can't be credited, and a configured linter is presence, not proof the rules actually run or block a merge.
- AX10 Code composition: Role is inferred from namespace/folder convention, not semantics — a domain concept living in a folder named "Services" reads as application, and the split is lines-of-code, not business value. The business-logic-share score is a SOFT, FLOORED signal: it contributes to the Architecture lens but is floored at the Critical gate, so an infrastructure-heavy design (a gateway, an ETL, a driver) is legitimately low without being nuked to zero.
- AX9 CQS / query purity: Handlers are found by interface/name convention — a query handler using neither is not seen. Mutation is a resolved write/publish invocation (SaveChanges/repository/bus), so a write hidden behind a hand-rolled wrapper, reflection, or a string-keyed service locator resolves to a non-persistence type and isn't flagged; it detects that a query writes state, not whether the write is a legitimate read-side cache update. Clean means "no resolved write/publish in a query body", not a proof of CQS purity.
- DM4 Rich vs anemic model: Behaviour is detected as state mutation inside a method body — a method that enforces an invariant by validating-and-throwing without mutating reads as a query, and mutation delegated through an interface the scan can't resolve isn't credited; entities with zero public properties still drop out of the population. It detects that state changes, not whether the rule is correct.
- DM6 Domain ↔ infrastructure boundary: Infrastructure reached through a hand-rolled wrapper, a domain-named facade, reflection, or a string-keyed service locator resolves to a non-infra type and isn't seen; the body scan is symbol resolution over syntax, not full dataflow. A clean result means "no resolved infra reference in a domain body", not a proof of purity.
- M4 Documentation accuracy: Onboarding quality is an LLM read of the docs/setup present — it cannot run the onboarding or measure how long a real new joiner takes; the verdict is sampled and advisory.
- P4 Deployment & Rollback: Approval/branch-protection rules live in repository settings the scan cannot see — only their in-repo evidence (config files, workflows) is checked, so a control enforced purely in the host's settings reads as "not evidenced".
The LLM boundary
Dimensions
D1 · Cyclomatic Complexity
0 method(s) exceeded the cyclomatic complexity threshold of 15.
D2 · Cognitive Complexity
0 method(s) exceeded the cognitive complexity threshold of 15.
D3 · God Classes
0 god class(es) detected.
D4 · Code Duplication
10 duplicated block group(s) detected. One further row reports members as variants of one another; it aggregates block groups already counted above and is not itself counted.
What to do
- Resolve the 2 Duplicated block (8 lines × 2) finding(s) in Code Duplication — start with HttpService.cs, Register.cshtml.cs. — One of this dimension's main actionable groups (2 warning-level).
- Resolve the 1 Members sharing a duplicated core (4 members, 50+ identical tokens) finding(s) in Code Duplication — start with HttpService.cs. — One of this dimension's main actionable groups (1 warning-level).
- Resolve the 1 Duplicated block (21 lines × 2) finding(s) in Code Duplication — start with REDACTED. — One of this dimension's main actionable groups (1 warning-level).
- Enforce Code Duplication in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Verified — provenance only; does not change the score.
D5 · Coupling
13 projects, 0 dependency cycle(s), 0 unstable depended-on project(s).
D6 · Cohesion (LCOM4)
1 of 27 classes have LCOM4 above 3.
What to do
- Resolve the 1 Low cohesion finding(s) in Cohesion (LCOM4) — start with CatalogItem.cs. — One of this dimension's main actionable groups (1 warning-level).
- Enforce Cohesion (LCOM4) in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Verified — provenance only; does not change the score.
D7 · Architectural Integrity
No mechanizable ADR was identified, so enforcement is not measured. Cycles found: 0.
What to do
- Enforce Architectural Integrity in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.
D9 · Test Distribution
102 test methods: 96 unit, 3 integration, 0 BDD, 3 e2e.
D10 · Test Quality
1 skipped (1 with a documented reason), 0 zero-assertion, 2 mock references across 102 tests.
D13 · REDACTED Scanning
5 secret(s) detected.
What to do
- Resolve the 7 Leaked secret finding(s) in REDACTED Scanning — start with REDACTED (4), REDACTED, REDACTED. — One of this dimension's main actionable groups (7 issue-level).
- Enforce REDACTED Scanning in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.
D14 · License Compliance
0 of 250 packages use a banned license. ★ DEPTH: this repository's MSBuild projects declare 69 direct `PackageReference`(s), and 181 further package(s) were reached beyond them by closing the graph over nuget.org's own nuspec dependency graph — so a banned licence pulled in only by a dependency's OWN dependencies is inside this verdict. A package whose licence nuget.org could not be asked for is not graded, and version ranges are taken at their lower bound, so this is the closure as that graph states it rather than a restored consumer's exact resolution. ★ COVERAGE OF THIS VERDICT: it grades this repository's NuGet package dependencies and nothing else. The repository also declares a Ruby Gemfile/Gemfile.lock or .gemspec (Bundler/RubyGems), and the licences of those dependencies were NOT read by this pass — a gap in this engine's coverage, not a statement about them. So this result says the graded closure carries no banned licence; it does NOT say this repository's licensing is clear.
D15 · Churn × Complexity Hotspots
No churn × complexity hotspots in the window.
D16 · Bus Factor
2 source file(s) have their living knowledge concentrated in one author (≥90% of recent, decayed contribution). The largest is BuildTestFormat.cs. Counted over 25 of the 277 production source files in this repository: 251 are under the ~2,400-byte size floor this dimension measures over, and the remaining 1 have no attributable history left to measure.
D17 · Explicit Debt
17 deducted debt markers + unmeasured dead symbols across 6912 LoC in the .NET projects (0.7/KLoC) → score 8.6. Dead code not measured: the solution did not load cleanly, so the reference search was skipped.
What to do
- Resolve the 6 FileScopedPragmaDisable finding(s) in Explicit Debt — start with Buyer.cs, Address.cs, CatalogItemOrdered.cs. — One of this dimension's main actionable groups (6 issue-level).
- Resolve the 8 TodoComment finding(s) in Explicit Debt — start with AccountControllerSignIn.cs (2), CustomAuthStateProvider.cs, Program.cs. — One of this dimension's main actionable groups (8 warning-level).
- Resolve the 1 Whole file has no live code finding(s) in Explicit Debt — start with AuthenticateEndpoint.cs. — One of this dimension's main actionable groups (1 warning-level).
- Enforce Explicit Debt in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.
D18 · Solution Shape
13 projects, 345 source files, 9435 hand-written lines of code (6912 production / 2523 test — the split is derived per file: test is what its project, its own path, or a compile-guarded region marks as test, and a file carrying no test signal counts as production), plus 2557 generated (machine-written code — designer, scaffolded and tool-emitted files — excluded from quality), 19 inter-project edges (build NOT measured — `dotnet build` did not complete in the analyzer, so the build half of this dimension is unmeasured rather than failed: the score above rests on structure alone and is not capped. The diagnostics that stopped it are named under Limitations.)
D19 · Documentation Quality
The repository's root README and a companion Getting Started for Beginners guide are excellent at explaining what the project is (an ASP.NET Core reference application showing single-process monolith architecture) and how to get it started. The documentation is well-structured with an exhaustive TOC covering overview video, eBook, topics, running via Azd template, local run, Docker, GitHub SSO, community extensions, and a dedicated EndToEndTests README that explains what the tests cover, first-time setup, and authoring workflows (codegen draft to artifact-producing run). The architecture/decision records are sparse but present in files like docs/_includes/head.html and decisions.md. There is no single unshown section missing from an outline; all visible documents are covered. The eShopOnWeb project's documentation is strong for its scope: the READMEs and architecture/Docs markdown files cover installation, .NET maintenance, Clean Architecture references, software design patterns (MVC, Razor Pages, API Endpoints, Mediator, Repository, Specification), and a detailed .NET Conf appearances list. The visible content is well-organized with clear headings; however, the summary reveals that XML-doc coverage for eShopWeb.AspireServiceDefaults, ApplicationCore, BlazorAdmin, BlazorShared, Infrastructure, PublicApi, and Web is below 2%, indicating many of the referenced NuGet packages are not documented at all. This leaves gaps in cross-package documentation (e.g., how to install/depend on ApplicationCore from eShopWeb.AspireServiceDefaults) that would be filled by a single package README rather than an architecture doc, and it is unclear whether the visible Clean Architecture references are sufficient for readers who need to decide which packages to add.
What to do
- Resolve the 1 Documentation finding(s) in Documentation Quality — start with patterns.md. — One of this dimension's main actionable groups (1 recommendation-level).
D20 · ADR Quality
Evaluated 2 ADR(s) individually; mean quality 3.0/10 (frequently incomplete). 2 flagged with a specific gap.
What to do
- Resolve the 1 The document is a boilerplate request with no context/problem and no… finding(s) in ADR Quality — start with 2025-04-24-document-decisions.md. — One of this dimension's main actionable groups (1 warning-level).
- Resolve the 1 No context/problem and no consequences/trade-offs; only implementation… finding(s) in ADR Quality — start with 2025-04-25-just-the-docs-theme.md. — One of this dimension's main actionable groups (1 warning-level).
D21 · Naming Consistency
0 naming inconsistencies across 200 sampled symbols.
D24 · Comment Value
42 valuable / 0 redundant across 105 sampled comments.
D26 · Project Cohesion
0 of 13 projects flagged as possibly oversized/incoherent.
D27 · Navigability
95 % of calls cross a namespace and 5 % go through an interface, but 80 % of collaborators are co-located — so following a call takes several hops. Baseline: small — navigation cost is tolerated.
What to do
- Improve Navigability — currently 8.8/10. — 95 % of calls cross a namespace and 5 % go through an interface, but 80 % of collaborators are co-located — so following a call takes several hops. Baseline: small — navigation cost is tolerated.
D28 · Secrets (history)
5 finding(s): 0 critical, 5 high, 0 medium, 0 low. Remediation for historically-committed secrets is credential rotation — they remain in history regardless of later deletion.
What to do
- Resolve the 4 High secret finding(s) in Secrets (history) — start with REDACTED (4). — One of this dimension's main actionable groups (4 issue-level).
- Resolve the 1 REDACTED finding(s) in Secrets (history) — start with REDACTED. — One of this dimension's main actionable groups (1 issue-level).
- Resolve the 1 Rotate the exposed credentials finding(s) in Secrets (history). — One of this dimension's main actionable groups (1 recommendation-level).
D29 · Static Analysis (SAST)
22 finding(s): 0 critical, 12 high, 9 medium, 1 low. 10 unpinned-GitHub-Actions row(s) are reported here but scored by D36 (supply-chain provenance), which measures that posture as `pinned_actions` — one pinning decision is charged once, not once per lens. semgrep hit a parse error in 38 file(s) — `docs/_includes/components/nav/links.html` (lines 1–9, line 33, lines 39–45, …), `docs/_includes/components/sidebar.html` (lines 1–10), `docs/_includes/components/site_nav.html` (lines 1–11, lines 19–22, line 27, …), `docs/_includes/head.html` (lines 1–11), `docs/_layouts/adr.html` (lines 1–3, line 10), … (+33 more) — so no absence of findings in the named regions is evidence of anything; rows reported elsewhere in those files are real. Fix the syntax error (or exclude the file deliberately) and re-scan to cover them. In 31 of those file(s) — `src/ApplicationCore/Entities/OrderAggregate/Events/OrderCreatedEvent.cs`, `src/ApplicationCore/Entities/OrderAggregate/Handlers/OrderCreatedHandler.cs`, `src/BlazorAdmin/Services/RoleManagementService.cs`, `src/BlazorAdmin/Services/UserManagementService.cs`, `src/Infrastructure/Identity/JwtSettingsValidator.cs`, … (+26 more) — the break is a C# primary constructor, which semgrep's grammar cannot parse and which hides the type from every rule scoped to it; those files were re-scanned from a shadow copy with the constructor's parameter list blanked (line and column preserving), which restores the type to the rules, and 0 additional row(s) came from that pass. Only the header's own parameter list is unread in them.
What to do
- Resolve the 1 REDACTED finding(s) in Static Analysis (SAST) — start with REDACTED. — One of this dimension's main actionable groups (1 issue-level).
- Resolve the 1 REDACTED finding(s) in Static Analysis (SAST) — start with REDACTED. — One of this dimension's main actionable groups (1 issue-level).
- No action in Static Analysis (SAST) — all 10 REDACTED finding(s) are reported here at file:line but scored by D36 (supply-chain provenance), so none is charged to this dimension. — One of this dimension's main actionable groups (10 issue-level, 0 of them charged here).
D30 · Dependency Vulnerabilities
5 finding(s): 0 critical, 4 high, 1 medium, 0 low. Partial dependency scan: 1 of 2 declared ecosystem(s) were scanned (nuget), and the findings above are real and complete for them. osv was not scanned (osv: the scanner produced no output at all, so no dependency was actually scanned), so this is not the whole dependency surface and the result is reported at reduced confidence.
What to do
- Resolve the 4 High CVE finding(s) in Dependency Vulnerabilities — start with REDACTED, REDACTED, REDACTED. — One of this dimension's main actionable groups (4 issue-level).
- Resolve the 1 Medium CVE finding(s) in Dependency Vulnerabilities — start with REDACTED. — One of this dimension's main actionable groups (1 warning-level).
D31 · IaC & Container Security
39 finding(s): 0 critical, 2 high, 36 medium, 1 low.
What to do
- Resolve the 36 Medium IaC finding(s) in IaC & Container Security — start with REDACTED (12), REDACTED (11), REDACTED (4). — One of this dimension's main actionable groups (36 warning-level).
- Resolve the 2 High IaC finding(s) in IaC & Container Security — start with REDACTED (2). — One of this dimension's main actionable groups (2 issue-level).
- Resolve the 1 Low IaC finding(s) in IaC & Container Security — start with REDACTED. — One of this dimension's main actionable groups (1 recommendation-level).
D34 · Knowledge Freshness
7 of 26 significant source file(s) are orphaned — their living knowledge has decayed to nothing, so no one currently understands them. The largest is src/BlazorAdmin/Services/HttpService.cs. Counted over 26 of the 277 production source files in this repository: the rest are under the ~2,400-byte size floor this dimension measures over.
What to do
- Resolve the 7 Orphaned file finding(s) in Knowledge Freshness — start with HttpService.cs, Extensions.cs, Login.cshtml.cs. — One of this dimension's main actionable groups (7 recommendation-level).
- Resolve the 1 Orphaned files with no living knowledge finding(s) in Knowledge Freshness. — One of this dimension's main actionable groups (1 recommendation-level).
D35 · Change Coupling
No strong hidden change-coupling between production files.
D36 · Supply-chain Provenance & Signing
0/4 supply-chain integrity signals present (provenance, signing, SBOM, pinned actions).
What to do
- Resolve the 3 REDACTED finding(s) in Supply-chain Provenance & Signing — start with REDACTED, REDACTED, REDACTED. — One of this dimension's main actionable groups (3 warning-level).
- Resolve the 1 REDACTED finding(s) in Supply-chain Provenance & Signing. — One of this dimension's main actionable groups (1 warning-level).
- Resolve the 1 REDACTED finding(s) in Supply-chain Provenance & Signing. — One of this dimension's main actionable groups (1 recommendation-level).
D44 · Platform End-of-Life
0 end-of-life runtime(s) and 0 end-of-life framework(s), read from 2 platform declaration(s) and 1 dependency declaration(s). This dimension reads what the repository says about ITSELF — a pinned target framework, a version file, a capped requires-python, a Rust toolchain pin, a framework major a constraint cannot move off. A FLOOR is deliberately never charged: `requires-python = ">=3.8"` states what the package SUPPORTS, not what it runs on, and a well-maintained library declares exactly that while running its own CI on a current release. The end-of-life facts are FROZEN and dated, so this dimension needs no network and answers identically inside a closed scan fence; as the table ages it loses recall and never precision, because a statement about support that ended in the past cannot become false. The OS layer of a container image is D31's question and the toolchain a CI workflow installs is D29's; this row is neither.
Frontend & cross-cutting dimensions
AC1 · Text alternatives
- An image with no alt (and no aria-label/aria-labelledby) is unreadable to assistive tech. Add alt — alt="" if it's purely decorative. (×19) — src/BlazorAdmin/Pages/CatalogItemPage/Create.razor:31, src/BlazorAdmin/Pages/CatalogItemPage/Delete.razor:29, src/BlazorAdmin/Pages/CatalogItemPage/Details.razor:30, …
- This interactive image has no accessible name. Add a non-empty alt (or aria-label) describing its action/destination — alt="" does not name an image button or link. — src/Web/Pages/Index.cshtml:20
What to do
- Add a text alternative — alt on images (alt="" for purely decorative ones), a title or aria-label on meaningful svg, an aria-label or inner fallback content on canvas, and a captions <track> on video.
AC2 · Forms & labels
- This <label> has no for and wraps no form control, so it names nothing: assistive tech never announces it, and clicking the caption focuses no field. Note that an id on the label is not an association — it is the TARGET of one, so a control still has to point at it. Give the label for="<the control's id>", move the control inside the label, or point the control's aria-labelledby at this label's id. (×12) — src/BlazorAdmin/Pages/CatalogItemPage/Create.razor:35, src/BlazorAdmin/Pages/CatalogItemPage/Create.razor:43, src/BlazorAdmin/Pages/CatalogItemPage/Create.razor:52, …
- This control has no associated label. Add a <label for> / wrapping <label> / aria-label / aria-labelledby so assistive tech can name it. — src/Web/Pages/Basket/Index.cshtml:39
What to do
- Give every control a programmatic label (a <label for> / wrapping <label> / aria-label) and every button text — a placeholder is not a label.
AC3 · Page structure
- No <main> (or role="main") means no "skip to content" target and a weaker landmark map. This layout renders the routed page body, so it is where the landmark belongs: wrap @Body in <main>. — src/BlazorAdmin/Shared/MainLayout.razor:7
- Skipping heading levels breaks the document outline assistive tech relies on. Don't jump levels — increase by at most one. (×3) — src/Web/Areas/Identity/Pages/Account/Register.cshtml:14, src/Web/Pages/Basket/Checkout.cshtml:78, src/Web/Views/Manage/_Layout.cshtml:7
- The page declares no language, so assistive tech can't pick the right pronunciation. Add lang (e.g. lang="en"). (×2) — src/Web/Pages/Admin/Index.cshtml:12, src/Web/Views/Shared/_Layout.cshtml:2
- user-scalable=no/0 or a maximum-scale below 2 stops low-vision users zooming to 200%. Remove the zoom restriction from the viewport meta. — src/Web/Pages/Admin/Index.cshtml:15
- A <table> with data cells but no <th> gives assistive technology no way to associate cells with their headers. Mark the header row/column cells as <th> (with a scope). — src/Web/Views/Manage/ExternalLogins.cshtml:10
- No <main> (or role="main") means no "skip to content" target and a weaker landmark map. Wrap the primary content in <main>. — src/Web/Views/Shared/_Layout.cshtml:2
What to do
- Declare <html lang>, a document <title> and a <main> landmark, keep headings in order, leave zoom enabled, title iframes and drop meta-refresh.
AC4 · Keyboard semantics
- This <div role="dialog"> is a modal dialog, but nothing moves focus into it when it opens and nothing keeps focus inside it while it is open, so a keyboard or screen-reader user keeps acting on the content behind it (WCAG 2.4.3). Use a native <dialog> opened with showModal(), a dialog component that traps focus, or move focus to the dialog on open, trap Tab inside it (or make the page behind inert) and return focus to the control that opened it on close. (×11) — src/BlazorAdmin/Pages/CatalogItemPage/Create.razor:9, src/BlazorAdmin/Pages/CatalogItemPage/Delete.razor:9, src/BlazorAdmin/Pages/CatalogItemPage/Details.razor:9, …
- A click handler on a plain element isn't keyboard-operable. Use a <button>, or add role + tabindex="0" + a key handler. (×2) — src/BlazorAdmin/Pages/CatalogItemPage/List.razor:39, src/BlazorAdmin/Shared/NavMenu.razor:9
What to do
- Make custom controls keyboard-operable (role + tabindex + key handler), drop positive tabindex, and give anchors a real href.
AC5 · ARIA correctness
AC6 · Visual & motion safety
- `.esh-catalog-send` sets color: #FFFFFF on background-color: #83D01B — 1.9:1, below the 4.5:1 WCAG AA minimum for normal text. Darken or lighten one of them. — src/Web/wwwroot/css/catalog/catalog.component.css:55
- `.esh-basket-checkout` sets color: #FFFFFF on background-color: #83D01B — 1.9:1, below the 4.5:1 WCAG AA minimum for normal text. Darken or lighten one of them. — src/Web/wwwroot/css/basket/basket.component.css:33
- `.esh-basketstatus-badge` sets color: #FFFFFF on background-color: #83D01B — 1.9:1, below the 4.5:1 WCAG AA minimum for normal text. Darken or lighten one of them. — src/Web/wwwroot/css/basket/basket-status/basket-status.component.css:13
- `.esh-identity-drop` moves (`transition: height 0.35s`) and nothing reads prefers-reduced-motion for it — no @media (prefers-reduced-motion) rule for this element, no reset this project loads — so a motion-sensitive user cannot turn it off (WCAG 2.3.3). Declare it under @media (prefers-reduced-motion: no-preference), or neutralise it under reduce. — src/Web/wwwroot/css/shared/components/identity/identity.css:39
- `.esh-identity:hover .esh-identity-drop` moves (`transition: height 0.35s`) and nothing reads prefers-reduced-motion for it — no @media (prefers-reduced-motion) rule for this element, no reset this project loads — so a motion-sensitive user cannot turn it off (WCAG 2.3.3). Declare it under @media (prefers-reduced-motion: no-preference), or neutralise it under reduce. — src/Web/wwwroot/css/shared/components/identity/identity.css:45
What to do
- Keep a visible focus style (don't remove the outline without a replacement), guard animation with prefers-reduced-motion, and raise low-contrast colour pairs to at least 4.5:1.
AC7 · A11y enforcement
- No accessibility enforcement found — no automated accessibility check runs over the HTML your app renders. Assert the accessibility invariants over that HTML in the test suite you already have (parse the output and assert, or drive a browser), and gate that test in CI so a regression blocks the merge. What was searched, so you can tell an absence from a miss: the 59 markup file(s) this pass actually assessed, the linter configuration checked in beside them, and this repository's test and CI files — matched by name against the accessibility checkers this dimension carries. An audit run outside the repository, a hosted scanner, or a check whose name is not one of those, is not seen here.
What to do
- Enforce accessibility in the test suite you already have: assert the accessibility invariants over the HTML your app renders — parse the rendered output in an existing test, or drive a real browser from one — and gate that test in CI so a regression blocks the merge.
AX1 · Captive dependencies
AX10 · Code composition
What to do
- The domain core is a small share of production code, but most of the rest matched no layer vocabulary at all — so this is not yet an anemic-domain finding. The namespace/path convention could not place that code, which makes the composition above a statement about the naming, not about the design. Name the layers (or check that the repository's conventions differ from the ones this check knows) before reading a thin domain into it.
AX2 · Stateful singletons
AX3 · Project dependency cycles
- The namespaces Microsoft.eShopWeb.ApplicationCore.Entities ↔ Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate ↔ Microsoft.eShopWeb.ApplicationCore.Entities.OrderAggregate ↔ Microsoft.eShopWeb.ApplicationCore.Interfaces depend on each other. The lightest dependency in the cycle is Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate → Microsoft.eShopWeb.ApplicationCore.Interfaces (Microsoft.eShopWeb.ApplicationCore.Entities.BasketAggregate.Basket → Microsoft.eShopWeb.ApplicationCore.Interfaces.IAggregateRoot, 1 type pair(s)); cut that one first, e.g. by moving the shared type to a namespace both can use or inverting it behind an interface. — src/ApplicationCore/Entities/BasketAggregate/Basket.cs:3
- The namespaces BlazorShared.Interfaces ↔ BlazorShared.Models depend on each other. The lightest dependency in the cycle is BlazorShared.Interfaces → BlazorShared.Models (BlazorShared.Interfaces.ICatalogItemService → BlazorShared.Models.CatalogItem, 2 type pair(s)); cut that one first, e.g. by moving the shared type to a namespace both can use or inverting it behind an interface. — src/BlazorShared/Interfaces/ICatalogItemService.cs:3
- The namespaces Microsoft.eShopWeb.PublicApi.UserManagementEndpoints ↔ Microsoft.eShopWeb.PublicApi.UserManagementEndpoints.Models depend on each other. The lightest dependency in the cycle is Microsoft.eShopWeb.PublicApi.UserManagementEndpoints.Models → Microsoft.eShopWeb.PublicApi.UserManagementEndpoints (Microsoft.eShopWeb.PublicApi.UserManagementEndpoints.Models.GetUserResponse → Microsoft.eShopWeb.PublicApi.UserManagementEndpoints.UserDto, 1 type pair(s)); cut that one first, e.g. by moving the shared type to a namespace both can use or inverting it behind an interface. — src/PublicApi/UserManagementEndpoints/Models/GetUserResponse.cs:5
- The namespaces Microsoft.eShopWeb.Web.Interfaces ↔ Microsoft.eShopWeb.Web.Pages.Basket depend on each other. The lightest dependency in the cycle is Microsoft.eShopWeb.Web.Interfaces → Microsoft.eShopWeb.Web.Pages.Basket (Microsoft.eShopWeb.Web.Interfaces.IBasketViewModelService → Microsoft.eShopWeb.Web.Pages.Basket.BasketViewModel, 1 type pair(s)); cut that one first, e.g. by moving the shared type to a namespace both can use or inverting it behind an interface. — src/Web/Interfaces/IBasketViewModelService.cs:2
What to do
- Break namespace cycles inside a project by moving the shared type to a namespace both sides can use, or by inverting the back edge behind an interface.
AX5 · Architecture & structure
AX6 · Interface segregation
AX8 · Test isolation
AX9 · CQS / query purity
C2 · Access Controls
DM1 · Aggregate boundaries
- `CatalogItem` references the aggregate root `CatalogType` directly (via `CatalogType`) — hold its `CatalogTypeId` instead. — src/ApplicationCore/Entities/CatalogItem.cs:14
- `CatalogItem` references the aggregate root `CatalogBrand` directly (via `CatalogBrand`) — hold its `CatalogBrandId` instead. — src/ApplicationCore/Entities/CatalogItem.cs:16
- `Basket` references the aggregate root `BasketItem` directly (via `_items`) — hold its `BasketItemId` instead. — src/ApplicationCore/Entities/BasketAggregate/Basket.cs:10
- `Basket` references the aggregate root `BasketItem` directly (via `Items`) — hold its `BasketItemId` instead. — src/ApplicationCore/Entities/BasketAggregate/Basket.cs:11
What to do
- Reference other aggregates by their strongly-typed id, never by object reference, so each aggregate stays an independent consistency boundary.
DM10 · One transaction, one aggregate
DM11 · Constructible invalid state
- `CatalogBrand`'s public constructor takes `brand` as raw primitives, and neither of the two things that would make that safe was found. What was searched, so you can tell an absence from a miss: for VALIDATION, the constructor body was scanned for `throw`, `Guard.`, `Ensure.`, `ArgumentNullException`, `ArgumentException`, `CheckRule` or `Requires.` — a guard reached through a helper method those tokens do not name is not seen; for a FACTORY, only this type's OWN static members were read, and only names beginning `Create`, `Of`, `From`, `New` or `Build` — one inherited from a base type, one on a companion builder, or one called `Parse`, `Make` or `Rehydrate` is not seen. If either exists, this row is wrong. If neither does, a caller can build a `CatalogBrand` that breaks the rules it exists to enforce, and every rule downstream then has to cope with a state the model said was impossible. Guard in the constructor, take value objects that validate themselves, or make the constructor private behind a `Create` that can refuse. — src/ApplicationCore/Entities/CatalogBrand.cs:8
- `CatalogItem`'s public constructor takes `catalogTypeId`, `catalogBrandId`, `description`, `name`, … as raw primitives, and neither of the two things that would make that safe was found. What was searched, so you can tell an absence from a miss: for VALIDATION, the constructor body was scanned for `throw`, `Guard.`, `Ensure.`, `ArgumentNullException`, `ArgumentException`, `CheckRule` or `Requires.` — a guard reached through a helper method those tokens do not name is not seen; for a FACTORY, only this type's OWN static members were read, and only names beginning `Create`, `Of`, `From`, `New` or `Build` — one inherited from a base type, one on a companion builder, or one called `Parse`, `Make` or `Rehydrate` is not seen. If either exists, this row is wrong. If neither does, a caller can build a `CatalogItem` that breaks the rules it exists to enforce, and every rule downstream then has to cope with a state the model said was impossible. Guard in the constructor, take value objects that validate themselves, or make the constructor private behind a `Create` that can refuse. — src/ApplicationCore/Entities/CatalogItem.cs:18
- `CatalogType`'s public constructor takes `type` as raw primitives, and neither of the two things that would make that safe was found. What was searched, so you can tell an absence from a miss: for VALIDATION, the constructor body was scanned for `throw`, `Guard.`, `Ensure.`, `ArgumentNullException`, `ArgumentException`, `CheckRule` or `Requires.` — a guard reached through a helper method those tokens do not name is not seen; for a FACTORY, only this type's OWN static members were read, and only names beginning `Create`, `Of`, `From`, `New` or `Build` — one inherited from a base type, one on a companion builder, or one called `Parse`, `Make` or `Rehydrate` is not seen. If either exists, this row is wrong. If neither does, a caller can build a `CatalogType` that breaks the rules it exists to enforce, and every rule downstream then has to cope with a state the model said was impossible. Guard in the constructor, take value objects that validate themselves, or make the constructor private behind a `Create` that can refuse. — src/ApplicationCore/Entities/CatalogType.cs:8
- `Basket`'s public constructor takes `buyerId` as raw primitives, and neither of the two things that would make that safe was found. What was searched, so you can tell an absence from a miss: for VALIDATION, the constructor body was scanned for `throw`, `Guard.`, `Ensure.`, `ArgumentNullException`, `ArgumentException`, `CheckRule` or `Requires.` — a guard reached through a helper method those tokens do not name is not seen; for a FACTORY, only this type's OWN static members were read, and only names beginning `Create`, `Of`, `From`, `New` or `Build` — one inherited from a base type, one on a companion builder, or one called `Parse`, `Make` or `Rehydrate` is not seen. If either exists, this row is wrong. If neither does, a caller can build a `Basket` that breaks the rules it exists to enforce, and every rule downstream then has to cope with a state the model said was impossible. Guard in the constructor, take value objects that validate themselves, or make the constructor private behind a `Create` that can refuse. — src/ApplicationCore/Entities/BasketAggregate/Basket.cs:16
- `OrderItem`'s public constructor takes `unitPrice`, `units` as raw primitives, and neither of the two things that would make that safe was found. What was searched, so you can tell an absence from a miss: for VALIDATION, the constructor body was scanned for `throw`, `Guard.`, `Ensure.`, `ArgumentNullException`, `ArgumentException`, `CheckRule` or `Requires.` — a guard reached through a helper method those tokens do not name is not seen; for a FACTORY, only this type's OWN static members were read, and only names beginning `Create`, `Of`, `From`, `New` or `Build` — one inherited from a base type, one on a companion builder, or one called `Parse`, `Make` or `Rehydrate` is not seen. If either exists, this row is wrong. If neither does, a caller can build a `OrderItem` that breaks the rules it exists to enforce, and every rule downstream then has to cope with a state the model said was impossible. Guard in the constructor, take value objects that validate themselves, or make the constructor private behind a `Create` that can refuse. — src/ApplicationCore/Entities/OrderAggregate/OrderItem.cs:12
What to do
- Give each aggregate one way in that can refuse — a guarded constructor, value-object parameters that validate themselves, or a private constructor behind a factory that returns a failure.
DM12 · Ambient inputs in the domain
DM2 · Strongly-typed ids
- `CatalogItem.CatalogTypeId` is a raw `Int32` — give it a strongly-typed id: a dedicated single-field type wrapping the `Int32`, in whatever form your language spells that. — src/ApplicationCore/Entities/CatalogItem.cs:13
- `CatalogItem.CatalogBrandId` is a raw `Int32` — give it a strongly-typed id: a dedicated single-field type wrapping the `Int32`, in whatever form your language spells that. — src/ApplicationCore/Entities/CatalogItem.cs:15
- `Basket.BuyerId` is a raw `String` — give it a strongly-typed id: a dedicated single-field type wrapping the `String`, in whatever form your language spells that. — src/ApplicationCore/Entities/BasketAggregate/Basket.cs:9
- `BasketItem.CatalogItemId` is a raw `Int32` — give it a strongly-typed id: a dedicated single-field type wrapping the `Int32`, in whatever form your language spells that. — src/ApplicationCore/Entities/BasketAggregate/BasketItem.cs:10
- `BasketItem.BasketId` is a raw `Int32` — give it a strongly-typed id: a dedicated single-field type wrapping the `Int32`, in whatever form your language spells that. — src/ApplicationCore/Entities/BasketAggregate/BasketItem.cs:11
- `PaymentMethod.CardId` is a raw `String` — give it a strongly-typed id: a dedicated single-field type wrapping the `String`, in whatever form your language spells that. — src/ApplicationCore/Entities/BuyerAggregate/PaymentMethod.cs:6
- `Order.BuyerId` is a raw `String` — give it a strongly-typed id: a dedicated single-field type wrapping the `String`, in whatever form your language spells that. — src/ApplicationCore/Entities/OrderAggregate/Order.cs:22
What to do
- Adopt strongly-typed ids across the domain — finish the migration or document the boundary; primitive ids invite transposed-argument bugs.
DM4 · Rich vs anemic model
- `CatalogBrand` is an aggregate/entity with 1 data propert(ies) but no state-changing behaviour (only data and queries) — the business logic lives in a service. — src/ApplicationCore/Entities/CatalogBrand.cs:5
- `CatalogType` is an aggregate/entity with 1 data propert(ies) but no state-changing behaviour (only data and queries) — the business logic lives in a service. — src/ApplicationCore/Entities/CatalogType.cs:5
- `Buyer` is an aggregate/entity with 2 data propert(ies) but no state-changing behaviour (only data and queries) — the business logic lives in a service. — src/ApplicationCore/Entities/BuyerAggregate/Buyer.cs:7
- `PaymentMethod` is an aggregate/entity with 3 data propert(ies) but no state-changing behaviour (only data and queries) — the business logic lives in a service. — src/ApplicationCore/Entities/BuyerAggregate/PaymentMethod.cs:3
- `Order` is an aggregate/entity with 4 data propert(ies) but no state-changing behaviour (only data and queries) — the business logic lives in a service. — src/ApplicationCore/Entities/OrderAggregate/Order.cs:8
- `OrderItem` is an aggregate/entity with 3 data propert(ies) but no state-changing behaviour (only data and queries) — the business logic lives in a service. — src/ApplicationCore/Entities/OrderAggregate/OrderItem.cs:3
What to do
- Move business rules onto the aggregates/entities they govern so invariants are enforced at the source, not in anemic services.
DM5 · Encapsulated state
DM6 · Domain ↔ infrastructure boundary
DM8 · Value-object opportunities
DM9 · Scattered domain decisions
GD1 · Unfinished & placeholder code
IC1 · Incompleteness & stubs
- `SendEmailAsync` looks like it should compute a result but its body just returns a constant — a placeholder return that was never filled in. — src/Infrastructure/Services/LoggerEmailSender.cs:8
- A placeholder e-mail address ("to@test.com") is still in shipped code — its domain is reserved for documentation, so anything sent here is undeliverable by construction. Replace it with the real address, or take it from configuration. — src/ApplicationCore/Entities/OrderAggregate/Handlers/OrderCreatedHandler.cs:16
- A line of code has been commented out rather than removed — dead weight that rots and confuses. Delete it (version control remembers). (×4) — src/PublicApi/AuthEndpoints/AuthenticateEndpoint.cs:37, src/Web/Areas/Identity/Pages/Account/Login.cshtml.cs:76, src/Web/Configuration/ConfigureCookieSettings.cs:14, …
- A test is skipped ("Intentional failure demo. Remove Skip to observe screenshot/video/trace artifacts.") — coverage that looks present but never runs in any gate. If it's an opt-in suite, document how it runs; otherwise re-enable or delete it. — tests/EndToEndTests/Playwright/BasketTests.cs:9
What to do
- Finish or delete the unfinished stubs (NotImplementedException / empty / constant-returning bodies) — they are dead surface that looks live.
- Clear the softer debt: remove commented-out code and dead branches, re-enable or delete skipped tests, and replace blanket warning suppressions with targeted ones.
M1 · Documentation (README)
- 27 code files changed in the last 6 months but the README was not touched — it may no longer reflect the system.
What to do
- Explain in the README how to run the tests. Add a section called Testing to the README in the repository's top folder, saying how to run the test suite.
- Add an 'Architecture' / 'How it works' section to the root README — the high-level shape.
- Add a README to the 11 of 13 project(s) that lack one — worth up to 1.7 pts.
- Review the README against recent changes; refresh the parts that drifted.
M2 · Architecture documentation
What to do
- Grow the ADR log (currently 2) — reach 8 to raise the maturity tier; document significant decisions as they're made.
M3 · Folder & project structure
M4 · Documentation accuracy
- README advertises a microservices architecture, but the repo is a single project with no service manifests — searched for: `microservice`, `service-mesh`, `istio`. Each was matched case- and separator-insensitively against file and directory NAMES anywhere in the tree, and against the CONTENTS of manifest and configuration files (package.json and other *.json, *.csproj, *.props, *.sln/*.slnx, *.yml, *.toml, *.config, tool configs such as eslint.config.js, REDACTED); the README's own prose never counts, so a claim is never refuted by merely being made. Nothing outside that search was read — a footprint living only in a submodule, in a file type not listed here, or under a name none of those terms matches is not seen, and this row is then wrong. — README.md:46
- docs/getting-started-for-beginners.md names `Startup.cs`, but no file or folder `Startup.cs` exists. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — docs/getting-started-for-beginners.md:105
- docs/walkthroughs/deploy-to-azure-app-service-from-azure-portal.md names `eShopOnWeb.sln`, but no file or folder `eShopOnWeb.sln` exists. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — docs/walkthroughs/deploy-to-azure-app-service-from-azure-portal.md:54
- docs/walkthroughs/deploying-windows-container-to-azure.md documents the environment variable `DS1_V2`, but no code, script or configuration file names it. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — docs/walkthroughs/deploying-windows-container-to-azure.md:23
What to do
- Reconcile the README with reality: README advertises a microservices architecture, but the repo is a single project with no service manifests; docs/getting-started-for-beginners.md names `Startup.cs`, but no file or folder `Startup.cs` exists; docs/walkthroughs/deploy-to-azure-app-service-from-azure-portal.md names `eShopOnWeb.sln`, but no file or folder `eShopOnWeb.sln` exists; docs/walkthroughs/deploying-windows-container-to-azure.md documents the environment variable `DS1_V2`, but no code, script or configuration file names it.
P1 · CI/CD gates
P2 · Observability
- Only 6/7 service-like projects use logging (pure contract/DTO projects are excluded — they have nothing to log). Of those 7, 3 ship a process this repository operates; the rest are libraries their consumer hosts, where the logging decision belongs to the host.
What to do
- Extend structured logging across the projects you operate, and give the library ones a diagnostics seam instead — an `EventSource`/`ActivitySource` the host can subscribe to, or an optional logger on your options object — rather than taking a logging dependency on your consumers' behalf.
P3 · Security & performance tooling
- No static application security testing detected. For this repository's stack, add CodeQL's csharp pack, or a .NET security analyzer package (or `semgrep --config=auto`, which runs on any language) as a CI step. What was searched, so you can tell an absence from a miss: the 3834 CI workflow file(s) in this repository, and the scanner and linter configuration checked in beside them. A scan that runs outside CI, one configured in your forge's web UI rather than in a committed file, or a tool whose name is none of those this check carries, is not seen — if that is your case the row is wrong, and saying so is more useful than adding a second scanner.
What to do
- Add a SAST step to CI running what this repository's stack ships: CodeQL's csharp pack, or a .NET security analyzer package — or `semgrep --config=auto`, which runs on any language — so a security regression fails the build instead of landing.
- Dependabot is configured but does not watch `github-actions`, `bundler` — add those `package-ecosystem` entries to REDACTED so those dependencies get the same automatic update and advisory pressure as the ones it already covers.
- Add gitleaks/trufflehog in CI to block PRs that introduce committed secrets.
P4 · Deployment & Rollback
- Deployment is orchestrated by compose, but no service declares a `healthcheck:` and nothing pins a previous image to fall back to — the runtime can tell that the container is up, not that it is serving, so a bad release is harder to detect and reverse.
What to do
- Add a `healthcheck:` to the served compose service — probing the endpoint it already answers on where it has one — with `depends_on: condition: service_healthy` on whatever waits for it, and keep the deployed image tag immutable and recorded so rolling back is re-pointing at the previous tag rather than rebuilding.
- Add an approval/environment gate (required reviewers / protection rules) before production promotion.
P7 · Outbound HTTP resilience
- `new HttpClient { BaseAddress = new Uri(builder.HostEnvironment.BaseAddress) }` builds an outbound HTTP client and nothing bounds it: no timeout is set on it and no retry or resilience policy wraps its calls in the type that owns it. A slow or failing dependency will hold this service's request, thread or connection — and cascade — until the call gives up on its own (100 s for HttpClient's default). — src/BlazorAdmin/Program.cs:25
- `new HttpClient { BaseAddress = new Uri("https+http://blazoradmin") }` builds an outbound HTTP client and nothing bounds it: no timeout is set on it and no retry or resilience policy wraps its calls in the type that owns it. A slow or failing dependency will hold this service's request, thread or connection — and cascade — until the call gives up on its own (100 s for HttpClient's default). — src/Web/Extensions/ServiceCollectionExtensions.cs:71
- `new HttpClient()` builds an outbound HTTP client and nothing bounds it: no timeout is set on it and no retry or resilience policy wraps its calls in the type that owns it. A slow or failing dependency will hold this service's request, thread or connection — and cascade — until the call gives up on its own (100 s for HttpClient's default). — src/Web/HealthChecks/HomePageHealthCheck.cs:21
What to do
- Add `AddStandardResilienceHandler()` (or a Polly policy and an explicit timeout) to each client registration flagged here, so a flaky dependency can't take the app down.
P8 · Schema migrations
PF3 · Async & latency hygiene
S1 · Web-Security Posture
- `https://ajax.aspnetcdn.com/ajax/jquery/jquery-2.2.0.min.js` is executed by this page with no Subresource Integrity. Whoever can answer that request — the CDN, anyone who compromises it, anyone on the network path — runs arbitrary script in this page's origin, with its session. The URL also names no version, so it resolves to whatever that origin serves at fetch time — the executed bytes can change with nobody touching this repository. 2 such include(s) across the repository's markup. — src/Web/Views/Shared/_Layout.cshtml:58
- `RequireHttpsMetadata = false` allows the OIDC discovery doc to be fetched over plain HTTP. Safe for loopback-only fetches (Aspire / on-host); risky for any other path. — src/PublicApi/Extensions/ServiceCollectionExtensions.cs:47
- None of the 11 security response headers the OWASP Secure Headers Project recommends (Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options, …) is configured — defense in depth, even when a reverse proxy could set them. (−2.0 on this card.)
- This web host's pipeline is composed here and adds no security response header (Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, a frame policy) to what it serves. (×2) — src/PublicApi/Program.cs:17, src/Web/Program.cs:14
What to do
- Pin third-party scripts and verify them: name an exact version in the URL and add an `integrity="sha384-…"` hash alongside `crossorigin="anonymous"` (both are required — an integrity hash on a cross-origin script without `crossorigin` is not evaluated, it blocks the script). Where the vendor ships a continuously-updated loader and publishes no stable hash (tag managers, analytics, chat widgets), Subresource Integrity is not available: constrain it instead with a `Content-Security-Policy` that names the exact origins allowed to execute, and drop the script from the pages that do not need it. Where the page is shipped inside a package that others host, prefer vendoring the asset and serving it from the app’s own origin, so no consumer inherits a third-party dependency they did not choose.
- Set RequireHttpsMetadata = true in prod (or pin MetadataAddress to a localhost URL the API can hit directly).
- Add security response headers (Content-Security-Policy first, then Strict-Transport-Security, X-Content-Type-Options and a frame policy) — defense in depth, even when a reverse proxy could set them.
X1 · Async correctness
- `async void` can't be awaited and its exceptions crash the process instead of propagating. Return `Task` — or, where the delegate contract requires void (timer/event/callback registrations), make this a thin void shim that awaits a Task-returning inner method inside try/catch so exceptions are contained. (×2) — src/BlazorAdmin/Pages/CatalogItemPage/List.razor.cs:43, src/BlazorAdmin/Pages/RolePage/List.razor.cs:34
What to do
- async void method: DetailsClick
X12 · Unreachable branch
X13 · Undrained process stream
X14 · Bypassable address classification
X15 · Unvalidated length from an untrusted reader
X16 · Unfloored truncation loop
X17 · Uncapped recursion over a caller-supplied document
X18 · Disposal-pattern correctness
- `client` is a `HttpClient`, which implements `IDisposable`, and it is created here (line 21). Every use of it in `CheckHealthAsync` reads a member through it — it is never returned, never stored, never handed to anything else, and never disposed — so this method both creates the value and is the last thing that can release it, and does not. Nothing announces the leak: the object holds its resource until finalization if its type has a finalizer, and until the process ends if it does not, so the cost accumulates once per CALL rather than showing up as a failure. Declare it with `using` (`using var client = …;`), which releases it at the end of the scope on every path including a throw. — src/Web/HealthChecks/HomePageHealthCheck.cs:21
What to do
- Each finding names the value and the span that decides who owns it — the `new` that created it, or the constructor parameter that handed it over. Confirm ownership from that span, then make the disposal match it: release what this type created, leave what it was injected with to whoever created THAT, and drop a finalizer whose type holds nothing unmanaged to release.
X19 · Unrestored process-global state
X2 · Cancellation propagation
- Only 28/133 async methods accept a CancellationToken, so in-flight work can't be stopped early when the caller gives up — whatever ends it in your host (shutdown signal, timeout, abandoned request, user cancel). Thread a token through the call chain and honour it at each await and loop; where a method genuinely cannot be interrupted, omitting it is a deliberate choice — judge against your hosting model.
- No CancellationToken parameter — this work can't be stopped early once started. (×38) — src/ApplicationCore/Services/BasketService.cs:23, src/ApplicationCore/Services/BasketService.cs:40, src/ApplicationCore/Services/BasketService.cs:47, …
- Neither takes a CancellationToken nor reads the one of the function it sits in, while it calls something that takes one — this work can't be stopped early once started. Take the token, or pass on the enclosing one. — src/BlazorAdmin/Program.cs:45
What to do
- Thread a CancellationToken through async methods so work stops promptly on cancellation.
X20 · Mistyped argument guard
X21 · Side-effecting pattern guard
X22 · Contradicted release guard
X23 · Unguarded diagnostic materialisation
X24 · Document value interpolated into markup unescaped
X25 · Inert configuration knob
X26 · Unsynchronised callback handoff
X27 · Collection changed while being enumerated
X28 · Index access outside its own emptiness guard
X29 · Per-element action decided by a fixed element
X3 · Exception handling
X30 · Support guard that admits what it rejects
X32 · Type resolved by simple name across every loaded assembly
X4 · Structured logging
- Logging an interpolated string (`$"..."`) collapses the event to plain text — you lose the named, queryable properties structured logging exists for. Use a message template with placeholders: `LogInformation("User {UserId} did {Action}", id, action)`. If these calls go through a logging wrapper that only accepts a pre-formatted string, give the wrapper a template+args overload that forwards to the underlying logger, then migrate call sites to it. (×3) — src/Infrastructure/Data/CatalogContextSeed.cs:54, src/Web/Configuration/RevokeAuthenticationEvents.cs:27, src/Web/Pages/Basket/Checkout.cshtml.cs:63
What to do
- Interpolated log message defeats structured logging
X5 · Nullable reference types
- 6/8 NRT-eligible project(s) enable <Nullable>enable</Nullable> (projects targeting a pre-C#-8 framework are excluded — NRTs aren't available there). NRTs catch a whole class of null-deref bugs at compile time.
- ~0.7 `!` suppressions per 1k syntax nodes — 26 suppression(s) across the 39065 syntax node(s) in code where nullable warnings are ENABLED, which is the only code a `!` can suppress anything in (a `!` under `#nullable disable` is inert and is not counted, and its file's nodes are not in the denominator). Each one tells the compiler to trust you about null, suppressing the very safety NRTs provide.
What to do
- Enable <Nullable>enable</Nullable> across all projects and resolve warnings rather than suppressing with `!`.
WCAG coverage — what static analysis assessed
| Dimension | WCAG 2.2 A/AA criteria | Coverage |
|---|---|---|
| AC1 · Text alternatives | 1.1.1, 1.2.2, 1.2.5 | Partial signal |
| AC2 · Forms & labels | 1.3.1, 3.3.2, 4.1.2 | Partial signal |
| AC3 · Page structure | 1.4.4, 2.2.1, 2.4.1, 2.4.2, 3.1.1, 4.1.2 | Partial signal |
| AC4 · Keyboard semantics | 2.1.1, 2.4.3 | Partial signal |
| AC5 · ARIA correctness | 4.1.2 | Partial signal |
| AC6 · Visual & motion safety | 1.4.3, 2.4.7 | Partial — literal CSS only |
| AC7 · A11y enforcement | enforcement — no page criterion | Enforcement posture (process) |
Reference — by lens
| Lens | Score | Rating | Impact |
|---|---|---|---|
| Code Health | 70% | Strong | Solid. |
| Architecture | 86% | Exemplary | Solid. |
| Maturity | 49% | Adequate — gated by M4 | Capped at Fair by a Critical contributor — resolve it before relying on this lens. |
| Readiness | 52% | Adequate — gated by D13, P3, P7 | Capped at Fair by a Critical contributor — resolve it before relying on this lens. |
| Security | 66% | Adequate — gated by D36 | Capped at Fair by a Critical contributor — resolve it before relying on this lens. |
| Domain Modelling | 54% | Adequate — gated by DM1, DM2 | Capped at Fair by a Critical contributor — resolve it before relying on this lens. |
| Accessibility | 33% | Weak — gated by AC1, AC4 | Capped at Fair by a Critical contributor — resolve it before relying on this lens. |
| Performance | 100% | Exemplary | Strongest area. |
Unscored — 2 check(s) recorded observations but carry no score
- P12 CI test-gate honesty — 1 observation(s) recorded · Reported, not scored — this card publishes what the CI gate does with the test inventory rather than grading it. The findings above are its output.
- X10 Duplicated predicate — 3 observation(s) recorded · Advisory — this card reports evidence and never carries a score.
Not evidenced — 5 control(s) we could not find positive evidence for
- C3 Audit Trail — Repo shows no audit-logging mechanism (IAuditable, an immutable audit log, an EF SaveChanges interceptor) for sensitive changes — absence of evidence is not evidence of a working control. Record an audit trail in code (or document where it lives) so this dimension can be scored.
- C4 Data Retention — Repo shows no data-retention / TTL / cleanup mechanism for personal data — absence of evidence is not evidence of a working control. Define retention periods and a purge/cleanup job (or TTL) in code, or document where retention is enforced, so this dimension can be scored.
- C5 Data-Subject Rights — Repo shows no corroborated data-subject-rights mechanism (erasure / export-portability / consent) tied to a subject id or GDPR vocabulary — absence of evidence is not evidence of a working control. Implement erasure, data export/portability and consent tracking over the subject's records.
- P5 DR & Backup — not evidenced — repo shows no backup/RTO/RPO controls; absence of evidence is not evidence of a working control
- P6 Release Hygiene — not evidenced — no changelog, version stamp or semver release tag in the repo
Not included — 31 check(s) not relevant to this codebase
- AX4 Dependency direction — not applicable to a CQRS architecture (the inward-dependency rule is for layered/clean styles)
- AX7 Slice cohesion — not applicable — not a vertical-slice architecture
- AXB2 Runtime readiness — Advisory — this card reports evidence and never carries a score, so there is nothing missing here.
- AXR1 Runtime accessibility — the Aspire AppHost did not expose a crawlable HTTP endpoint in time (or only the dashboard) — no runtime evidence This is a statement about this run, not a statement about your application: nothing here says the surface is inaccessible, only that it was never rendered.
- C1 Data Protection — This is a dotnet-new template — at-rest encryption and key-vaulting are deferred to the application you build from it. Add ASP.NET Data Protection / column encryption + a key vault for your real data store when you productionise.
- D11 Test Reliability — Test runner surfaced no tests
- D12 Dependency Hygiene — Dependency hygiene not measured
- D22 Internal API Consistency — No intentionally-exposed public API to evaluate for consistency.
- D23 Boundary Type-Coupling — small single-context codebase (6,912 production LoC in the .NET projects) — bounded contexts are not needed at this size No bounded-context organisation was detected either — neither a context-shaped layout, nor 2+ sibling source directories each declaring an aggregate root, nor 2+ projects each declaring an entity of their own. Aggregate roots were found in only one source directory (ApplicationCore), which is a layered codebase, not two contexts. Declaring this codebase's bounded contexts (≥2) would let cross-boundary type coupling be assessed. Declare them in `.codehealth/config.yaml` at the repository root (create it if absent), mapping each context name to the module-path or namespace prefixes that belong to it — e.g. `architecture:` → `contexts:` → `Billing: ["src/billing", "Acme.Billing"]`, `Catalog: ["src/catalog", "Acme.Catalog"]`.
- D25 ADR Conformance — none of 2 ADRs are conformance-checkable — unverifiable.
- D32 Data Compliance (PII/GDPR) — 31 file(s) were not parsed by semgrep — the PII/GDPR ruleset never ran over them
- D37 Vulnerability-disclosure Policy — No vulnerability-disclosure policy file found (SECURITY.md/.markdown/.rst/.txt at root or under .github/.forgejo/.gitea/docs, .well-known/security.txt). A coordinated-disclosure policy may live off-repo, so this is not evidenced rather than failed.
- D39 IL Efficiency — IL not measured — the target did not build
- D40 Network Egress Confinement — No Kubernetes/orchestration workloads found in the repository manifests; network egress policy is a cluster-native control that may live at the platform/firewall layer, so there is nothing to assess here.
- D41 Kernel & Syscall Confinement — No Kubernetes/orchestration workloads found in the repository manifests; seccomp/AppArmor/SELinux confinement is a workload-level control, so there is nothing to assess here.
- D42 Runtime Threat Enforcement — No Kubernetes/orchestration workloads found in the repository manifests; runtime threat-detection and admission-control policy are cluster-level controls, so there is nothing to assess here.
- D43 Malicious Dependencies — Scanner failed to run — not a clean result
- D8 Code Coverage — Coverage NOT MEASURED: this repository did not build in our analyzer environment (a C#/MSBuild compiler error), so no coverage could be collected. It is excluded from the score rather than counted as a near-zero defect. We did not read WHERE the failing diagnostic is, so this does not claim the fault is in your test code — a repository written for an older SDK band can compile for you and not for us. Run `dotnet build` on this commit; if it succeeds, the gap is ours. Committing the Cobertura/OpenCover/lcov report your CI already produces also lets us measure real coverage without building anything.
- DM3 Integration-event coupling — no integration events detected — coupling check not applicable
- DM7 Repository granularity — no repository abstraction detected (e.g. uses a document session)
- ED1 Event-Driven — applicable but not scored (2 of 3 signals for this style — below the bar we score at): 1 event handler(s); 3 CQRS handler(s)
- ED5 Idempotency — 1 mutating command handler(s)/consumer(s) detected and 1 handler method(s) walked, but no persistent write was recognised in any of them — idempotency not assessed
- ES1 Event Sourcing — not scored — this repository shows none of the 3 signals this lens looks for
- P9 Domain vs controller coverage — no coverage report found on disk — produce a coverage report in a standard format (Cobertura — `dotnet test --collect:"XPlat Code Coverage"` with a `coverlet.collector` PackageReference) and commit it — a hosted scan measures a clone of the repository, so a report that exists only in a working tree, a CI runner's or your own, never reaches it; the artefact is commonly gitignored, so `git add -f` that one file (or un-ignore its path) and commit it alongside the code it measures, or wire coverage collection into CI, to enable this cross-layer check
- PF1 Benchmark discipline — Performance is assessed only for perf-relevant repos — a packaged library, one that ships benchmarks, or one already using allocation-aware APIs. This repo isn't one, so the Performance lens is not applicable and is excluded from the score.
- PF2 Allocation hygiene — Performance is assessed only for perf-relevant repos — a packaged library, one that ships benchmarks, or one already using allocation-aware APIs. This repo isn't one, so the Performance lens is not applicable and is excluded from the score.
- SC1 Supply-chain hygiene — Advisory — this card reports evidence and never carries a score, so there is nothing missing here.
- X6 Hand-rolled structured-format parsing — Advisory — this card reports evidence and never carries a score, so there is nothing missing here.
- X7 Silent fallback defaults — Advisory — this card reports evidence and never carries a score, so there is nothing missing here.
- X8 JS interop contract — Advisory — this card reports evidence and never carries a score, so there is nothing missing here.
- X9 Subsumed condition operand — Advisory — this card reports evidence and never carries a score, so there is nothing missing here.
Appendix A — Findings (grouped)
Critical — 82 finding(s)
- <img> without a text alternative src/BlazorAdmin/Pages/CatalogItemPage/Create.razor:31
- <img> without a text alternative src/BlazorAdmin/Pages/CatalogItemPage/Delete.razor:29
- <img> without a text alternative src/BlazorAdmin/Pages/CatalogItemPage/Details.razor:30
- <img> without a text alternative src/BlazorAdmin/Pages/CatalogItemPage/Edit.razor:32
- <img> without a text alternative src/BlazorAdmin/Pages/CatalogItemPage/List.razor:41
- <img> without a text alternative src/Web/Pages/Admin/EditCatalogItem.cshtml:10
- <img> without a text alternative src/Web/Pages/Basket/Checkout.cshtml:8
- <img> without a text alternative src/Web/Pages/Basket/Checkout.cshtml:33
- <img> without a text alternative src/Web/Pages/Basket/Index.cshtml:8
- <img> without a text alternative src/Web/Pages/Basket/Index.cshtml:33
- <img> without a text alternative src/Web/Pages/Basket/Success.cshtml:9
- <img> without a text alternative src/Web/Pages/Index.cshtml:8
- <img> without a text alternative src/Web/Pages/Shared/Components/BasketComponent/Default.cshtml:8
- <img> without a text alternative src/Web/Pages/Shared/_editCatalog.cshtml:5
- <img> without a text alternative src/Web/Pages/Shared/_product.cshtml:4
- <img> without a text alternative src/Web/Views/Order/Detail.cshtml:55
- <img> without a text alternative src/Web/Views/Shared/Components/Basket/Default.cshtml:9
- <img> without a text alternative src/Web/Views/Shared/_LoginPartial.cshtml:8
- <img> without a text alternative src/Web/Views/Shared/_LoginPartial.cshtml:31
- <label> that labels no control src/BlazorAdmin/Pages/CatalogItemPage/Create.razor:35
- <label> that labels no control src/BlazorAdmin/Pages/CatalogItemPage/Create.razor:43
- <label> that labels no control src/BlazorAdmin/Pages/CatalogItemPage/Create.razor:52
- <label> that labels no control src/BlazorAdmin/Pages/CatalogItemPage/Create.razor:65
- <label> that labels no control src/BlazorAdmin/Pages/CatalogItemPage/Create.razor:78
- <label> that labels no control src/BlazorAdmin/Pages/CatalogItemPage/Edit.razor:37
- <label> that labels no control src/BlazorAdmin/Pages/CatalogItemPage/Edit.razor:45
- <label> that labels no control src/BlazorAdmin/Pages/CatalogItemPage/Edit.razor:55
- <label> that labels no control src/BlazorAdmin/Pages/CatalogItemPage/Edit.razor:68
- <label> that labels no control src/BlazorAdmin/Pages/CatalogItemPage/Edit.razor:81
- <label> that labels no control src/BlazorAdmin/Pages/RolePage/Create.razor:31
- <label> that labels no control src/BlazorAdmin/Pages/RolePage/Edit.razor:35
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- FileScopedPragmaDisable src/ApplicationCore/Entities/BuyerAggregate/Buyer.cs:15
- FileScopedPragmaDisable src/ApplicationCore/Entities/OrderAggregate/Address.cs:15
- FileScopedPragmaDisable src/ApplicationCore/Entities/OrderAggregate/CatalogItemOrdered.cs:22
- FileScopedPragmaDisable src/ApplicationCore/Entities/OrderAggregate/Order.cs:10
- FileScopedPragmaDisable src/ApplicationCore/Entities/OrderAggregate/OrderItem.cs:9
- FileScopedPragmaDisable src/Infrastructure/Data/CatalogContext.cs:11
- Namespace dependency cycle src/ApplicationCore/Entities/BasketAggregate/Basket.cs:3
- Namespace dependency cycle src/BlazorShared/Interfaces/ICatalogItemService.cs:3
- Namespace dependency cycle src/PublicApi/UserManagementEndpoints/Models/GetUserResponse.cs:5
- Namespace dependency cycle src/Web/Interfaces/IBasketViewModelService.cs:2
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- Aggregate holds a reference to another aggregate: CatalogItem.CatalogType src/ApplicationCore/Entities/CatalogItem.cs:14
- Aggregate holds a reference to another aggregate: CatalogItem.CatalogBrand src/ApplicationCore/Entities/CatalogItem.cs:16
- Aggregate holds a reference to another aggregate: Basket._items src/ApplicationCore/Entities/BasketAggregate/Basket.cs:10
- Aggregate holds a reference to another aggregate: Basket.Items src/ApplicationCore/Entities/BasketAggregate/Basket.cs:11
- <html> without a lang src/Web/Pages/Admin/Index.cshtml:12
- <html> without a lang src/Web/Views/Shared/_Layout.cshtml:2
- REDACTED
- REDACTED
- <input> without a text alternative src/Web/Pages/Index.cshtml:20
- <input> without a programmatic label src/Web/Pages/Basket/Index.cshtml:39
- Viewport restricts zoom src/Web/Pages/Admin/Index.cshtml:15
- Click handler on a non-interactive <tr> src/BlazorAdmin/Pages/CatalogItemPage/List.razor:39
- Click handler on a non-interactive <div> src/BlazorAdmin/Shared/NavMenu.razor:9
- REDACTED
- REDACTED
- REDACTED
Serious — 158 finding(s)
- Async method without CancellationToken: AddItemToBasket src/ApplicationCore/Services/BasketService.cs:23
- Async method without CancellationToken: DeleteBasketAsync src/ApplicationCore/Services/BasketService.cs:40
- Async method without CancellationToken: SetQuantities src/ApplicationCore/Services/BasketService.cs:47
- Async method without CancellationToken: TransferBasketAsync src/ApplicationCore/Services/BasketService.cs:66
- Async method without CancellationToken: CreateOrderAsync src/ApplicationCore/Services/OrderService.cs:34
- Async method without CancellationToken: GetUser src/BlazorAdmin/CustomAuthStateProvider.cs:36
- Async method without CancellationToken: FetchUser src/BlazorAdmin/CustomAuthStateProvider.cs:50
- Async method without CancellationToken: DeleteCookie src/BlazorAdmin/JavaScript/Cookies.cs:15
- Async method without CancellationToken: GetCookie src/BlazorAdmin/JavaScript/Cookies.cs:20
- Async method without CancellationToken: ShowBodyOverflow src/BlazorAdmin/JavaScript/Css.cs:15
- Async method without CancellationToken: HideBodyOverflow src/BlazorAdmin/JavaScript/Css.cs:20
- Async method without CancellationToken: RouteOutside src/BlazorAdmin/JavaScript/Route.cs:15
- Async method without CancellationToken: ListPaged src/BlazorAdmin/Services/CachedCatalogItemServiceDecorator.cs:27
- Async method without CancellationToken: List src/BlazorAdmin/Services/CachedCatalogItemServiceDecorator.cs:51
- Async method without CancellationToken: GetById src/BlazorAdmin/Services/CachedCatalogItemServiceDecorator.cs:75
- Async method without CancellationToken: Create src/BlazorAdmin/Services/CachedCatalogItemServiceDecorator.cs:80
- Async method without CancellationToken: Edit src/BlazorAdmin/Services/CachedCatalogItemServiceDecorator.cs:88
- Async method without CancellationToken: Delete src/BlazorAdmin/Services/CachedCatalogItemServiceDecorator.cs:96
- Async method without CancellationToken: RefreshLocalStorageList src/BlazorAdmin/Services/CachedCatalogItemServiceDecorator.cs:102
- Async method without CancellationToken: List src/BlazorAdmin/Services/CachedCatalogLookupDataServiceDecorator .cs:29
- Async method without CancellationToken: Create src/BlazorAdmin/Services/CatalogItemService.cs:29
- Async method without CancellationToken: Edit src/BlazorAdmin/Services/CatalogItemService.cs:35
- Async method without CancellationToken: Delete src/BlazorAdmin/Services/CatalogItemService.cs:40
- Async method without CancellationToken: GetById src/BlazorAdmin/Services/CatalogItemService.cs:45
- Async method without CancellationToken: ListPaged src/BlazorAdmin/Services/CatalogItemService.cs:59
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- Modal dialog does not manage focus src/BlazorAdmin/Pages/CatalogItemPage/Create.razor:9
- Modal dialog does not manage focus src/BlazorAdmin/Pages/CatalogItemPage/Delete.razor:9
- Modal dialog does not manage focus src/BlazorAdmin/Pages/CatalogItemPage/Details.razor:9
- Modal dialog does not manage focus src/BlazorAdmin/Pages/CatalogItemPage/Edit.razor:9
- Modal dialog does not manage focus src/BlazorAdmin/Pages/RolePage/Create.razor:9
- Modal dialog does not manage focus src/BlazorAdmin/Pages/RolePage/Delete.razor:14
- Modal dialog does not manage focus src/BlazorAdmin/Pages/RolePage/DeleteUserFromRole.razor:14
- Modal dialog does not manage focus src/BlazorAdmin/Pages/RolePage/Edit.razor:12
- Modal dialog does not manage focus src/BlazorAdmin/Pages/UserPage/Create.razor:11
- Modal dialog does not manage focus src/BlazorAdmin/Pages/UserPage/Delete.razor:13
- Modal dialog does not manage focus src/BlazorAdmin/Pages/UserPage/Edit.razor:13
- TodoComment src/BlazorAdmin/CustomAuthStateProvider.cs:15
- TodoComment src/PublicApi/Program.cs:49
- TodoComment src/Web/Areas/Identity/Pages/Account/Logout.cshtml.cs:13
- TodoComment src/Web/Configuration/ConfigureCookieSettings.cs:13
- TodoComment src/Web/Configuration/RevokeAuthenticationEvents.cs:8
- TodoComment tests/FunctionalTests/Web/Controllers/AccountControllerSignIn.cs:34
- TodoComment tests/FunctionalTests/Web/Controllers/AccountControllerSignIn.cs:35
- TodoComment src/BlazorAdmin/Pages/CatalogItemPage/Delete.razor:110
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- Anemic entity: CatalogBrand src/ApplicationCore/Entities/CatalogBrand.cs:5
- Anemic entity: CatalogType src/ApplicationCore/Entities/CatalogType.cs:5
- Anemic entity: Buyer src/ApplicationCore/Entities/BuyerAggregate/Buyer.cs:7
- Anemic entity: PaymentMethod src/ApplicationCore/Entities/BuyerAggregate/PaymentMethod.cs:3
- Anemic entity: Order src/ApplicationCore/Entities/OrderAggregate/Order.cs:8
- Anemic entity: OrderItem src/ApplicationCore/Entities/OrderAggregate/OrderItem.cs:3
- Constructible in an invalid state: CatalogBrand src/ApplicationCore/Entities/CatalogBrand.cs:8
- Constructible in an invalid state: CatalogItem src/ApplicationCore/Entities/CatalogItem.cs:18
- Constructible in an invalid state: CatalogType src/ApplicationCore/Entities/CatalogType.cs:8
- Constructible in an invalid state: Basket src/ApplicationCore/Entities/BasketAggregate/Basket.cs:16
- Constructible in an invalid state: OrderItem src/ApplicationCore/Entities/OrderAggregate/OrderItem.cs:12
- Low contrast colour pair in CSS (1.9:1) src/Web/wwwroot/css/catalog/catalog.component.css:55
- Low contrast colour pair in CSS (1.9:1) src/Web/wwwroot/css/basket/basket.component.css:33
- Low contrast colour pair in CSS (1.9:1) src/Web/wwwroot/css/basket/basket-status/basket-status.component.css:13
- REDACTED
- REDACTED
- REDACTED
- Outbound HTTP without resilience src/BlazorAdmin/Program.cs:25
- Outbound HTTP without resilience src/Web/Extensions/ServiceCollectionExtensions.cs:71
- Outbound HTTP without resilience src/Web/HealthChecks/HomePageHealthCheck.cs:21
- Page without a main landmark src/BlazorAdmin/Shared/MainLayout.razor:7
- Page without a main landmark src/Web/Views/Shared/_Layout.cshtml:2
- Heading level jumps from h2 to h4 src/Web/Areas/Identity/Pages/Account/Register.cshtml:14
- Heading level jumps from h2 to h4 src/Web/Views/Manage/_Layout.cshtml:7
- Animation without a prefers-reduced-motion guard src/Web/wwwroot/css/shared/components/identity/identity.css:39
- Animation without a prefers-reduced-motion guard src/Web/wwwroot/css/shared/components/identity/identity.css:45
- REDACTED
- REDACTED
- Duplicated block (8 lines × 2) src/BlazorAdmin/Services/HttpService.cs:71
- Duplicated block (8 lines × 2) src/Web/Areas/Identity/Pages/Account/Register.cshtml.cs:47
- async void method: DetailsClick src/BlazorAdmin/Pages/CatalogItemPage/List.razor.cs:43
- async void method: DetailsClick src/BlazorAdmin/Pages/RolePage/List.razor.cs:34
- Heading level jumps from h1 to h3 src/Web/Pages/Basket/Checkout.cshtml:78
- Data table has no header cells src/Web/Views/Manage/ExternalLogins.cshtml:10
- Accessibility enforcement below the top rung
- Whole file has no live code — 2 debt markers inside it tests/FunctionalTests/PublicApi/AuthEndpoints/AuthenticateEndpoint.cs:1
- CommentedOutCode src/eShopWeb.AspireServiceDefaults/Extensions.cs:88
- The document is a boilerplate request with no context/problem and no consequences; only the decisioner's name and where ADRs live are present docs/decisions/2025-04-24-document-decisions.md
- No context/problem and no consequences/trade-offs; only implementation rationale is present docs/decisions/2025-04-25-just-the-docs-theme.md
- REDACTED
- REDACTED
- REDACTED
- Members sharing a duplicated core (4 members, 50+ identical tokens) src/BlazorAdmin/Services/HttpService.cs:53
- Duplicated block (21 lines × 2) src/PublicApi/Extensions/WebApplicationExtensions.cs:18
- Duplicated block (15 lines × 2) src/BlazorAdmin/Services/CachedCatalogItemServiceDecorator.cs:29
- Duplicated block (13 lines × 2) src/BlazorAdmin/Services/HttpService.cs:55
- Duplicated block (11 lines × 2) src/BlazorAdmin/Services/CatalogItemService.cs:66
- Duplicated block (12 lines × 2) src/Web/ViewModels/Manage/ChangePasswordViewModel.cs:12
- Duplicated block (11 lines × 3) src/BlazorAdmin/Services/HttpService.cs:54
- Duplicated block (10 lines × 2) src/Web/Areas/Identity/Pages/Account/Logout.cshtml.cs:33
- Duplicated block (7 lines × 2) src/BlazorShared/Models/CatalogItem.cs:80
- Low cohesion: CatalogItem (LCOM4 4) src/ApplicationCore/Entities/CatalogItem.cs:7
- Coverage not measured — test suite did not build
- Hollow method — returns a constant without doing the work src/Infrastructure/Services/LoggerEmailSender.cs:8
- README may be stale
- Coverage collected but not gated
- Third-party script without Subresource Integrity src/Web/Views/Shared/_Layout.cshtml:58
- Disposable created and abandoned in the method that made it src/Web/HealthChecks/HomePageHealthCheck.cs:21
- Async local function without CancellationToken: ClearLocalStorageCache src/BlazorAdmin/Program.cs:45
Minor — 49 finding(s)
- Orphaned file src/BlazorAdmin/Services/HttpService.cs:1
- Orphaned file src/eShopWeb.AspireServiceDefaults/Extensions.cs:1
- Orphaned file src/Web/Areas/Identity/Pages/Account/Login.cshtml.cs:1
- Orphaned file src/Web/Extensions/ServiceCollectionExtensions.cs:1
- Orphaned file src/Web/Areas/Identity/Pages/Account/Register.cshtml.cs:1
- Orphaned file src/Web/Areas/Identity/Helpers/GitHubClaimsHelper.cs:1
- Orphaned file src/BlazorShared/Models/CatalogItem.cs:1
- Primitive id on a domain type: CatalogItem.CatalogTypeId src/ApplicationCore/Entities/CatalogItem.cs:13
- Primitive id on a domain type: CatalogItem.CatalogBrandId src/ApplicationCore/Entities/CatalogItem.cs:15
- Primitive id on a domain type: Basket.BuyerId src/ApplicationCore/Entities/BasketAggregate/Basket.cs:9
- Primitive id on a domain type: BasketItem.CatalogItemId src/ApplicationCore/Entities/BasketAggregate/BasketItem.cs:10
- Primitive id on a domain type: BasketItem.BasketId src/ApplicationCore/Entities/BasketAggregate/BasketItem.cs:11
- Primitive id on a domain type: PaymentMethod.CardId src/ApplicationCore/Entities/BuyerAggregate/PaymentMethod.cs:6
- Primitive id on a domain type: Order.BuyerId src/ApplicationCore/Entities/OrderAggregate/Order.cs:22
- Commented-out code src/PublicApi/AuthEndpoints/AuthenticateEndpoint.cs:37
- Commented-out code src/Web/Areas/Identity/Pages/Account/Login.cshtml.cs:76
- Commented-out code src/Web/Configuration/ConfigureCookieSettings.cs:14
- Commented-out code src/Web/Program.cs:128
- README/code drift README.md:46
- README/code drift docs/getting-started-for-beginners.md:105
- README/code drift docs/walkthroughs/deploy-to-azure-app-service-from-azure-portal.md:54
- README/code drift docs/walkthroughs/deploying-windows-container-to-azure.md:23
- No security response headers detected
- No security response headers detected src/PublicApi/Program.cs:17
- No security response headers detected src/Web/Program.cs:14
- Duplicated predicate src/ApplicationCore/Specifications/CatalogFilterPaginatedSpecification.cs:16
- Duplicated predicate src/PublicApi/Extensions/WebApplicationExtensions.cs:30
- Duplicated predicate src/BlazorShared/Models/CatalogItem.cs:82
- Interpolated log message defeats structured logging src/Infrastructure/Data/CatalogContextSeed.cs:54
- Interpolated log message defeats structured logging src/Web/Configuration/RevokeAuthenticationEvents.cs:27
- Interpolated log message defeats structured logging src/Web/Pages/Basket/Checkout.cshtml.cs:63
- Off-boarding risk: anonymized user #1
- Documentation: hard to navigate docs/explore/patterns.md
- REDACTED
- REDACTED
- REDACTED
- Orphaned files with no living knowledge
- REDACTED
- REDACTED
- REDACTED
- Placeholder data left in code src/ApplicationCore/Entities/OrderAggregate/Handlers/OrderCreatedHandler.cs:16
- Disabled test tests/EndToEndTests/Playwright/BasketTests.cs:9
- Logging is not universal
- No SAST
- No rollback/health safety
- OIDC metadata fetched over HTTP src/PublicApi/Extensions/ServiceCollectionExtensions.cs:47
- Not all async methods take a CancellationToken
- Nullable reference types not enabled everywhere
- Null-forgiving operator (`!`) suppressions reduce the NRT score
Minor — 11 finding(s)
- XML-doc coverage: eShopWeb.AspireServiceDefaults src/eShopWeb.AspireServiceDefaults/eShopWeb.AspireServiceDefaults.csproj
- XML-doc coverage: ApplicationCore src/ApplicationCore/ApplicationCore.csproj
- XML-doc coverage: BlazorAdmin src/BlazorAdmin/BlazorAdmin.csproj
- XML-doc coverage: BlazorShared src/BlazorShared/BlazorShared.csproj
- XML-doc coverage: Infrastructure REDACTED
- XML-doc coverage: PublicApi REDACTED
- XML-doc coverage: Web src/Web/Web.csproj
- Mock framework: NSubstitute
- Mock framework: NSubstitute
- Skipped (documented): Cart_AddItem_ShowsExpectedTotal tests/EndToEndTests/Playwright/BasketTests.cs:9
- Off the main sequence: BlazorShared src/BlazorShared/BlazorShared.csproj:1
Appendix B — Reproduction & audit trail
| Dimension | Tool | Version | Command | Findings | Raw output |
|---|---|---|---|---|---|
| D28 · Secrets (history) | gitleaks | — | gitleaks detect --no-banner --config /opt/gitleaks-rules/watchdog-gitleaks.toml --report-format json --report-path /tmp/watchdog-gitleaks-53c083f1ae4045ee8cea144c238fe728/history.json --exit-code 0 --source . | 2 | artifacts/raw/gitleaks-history.json |
| D28 · Secrets (history) | gitleaks | — | gitleaks detect --no-git --no-banner --config /opt/gitleaks-rules/watchdog-gitleaks.toml --report-format json --report-path /tmp/watchdog-gitleaks-53c083f1ae4045ee8cea144c238fe728/tree.json --exit-code 0 --source . | 0 | artifacts/raw/gitleaks-tree.json |
| D29 · Static Analysis (SAST) | semgrep | — | semgrep --config /opt/semgrep-rules/security-audit.yml --config /opt/semgrep-rules/owasp-top-ten.yml --config /opt/semgrep-rules/watchdog-sast.yml --json --quiet --timeout 10 --timeout-threshold 3 --metrics off . | 22 | artifacts/raw/semgrep.json |
| D30 · Dependency Vulnerabilities | dotnet | — | dotnet list eShopOnWeb.slnx package --vulnerable --include-transitive --format json | 5 | artifacts/raw/dotnet-vulnerable.json |
| D30 · Dependency Vulnerabilities | osv-scanner | — | osv-scanner --format json --recursive --experimental-disable-plugins transitivedependency/requirements --experimental-disable-plugins dotnet/csproj --experimental-disable-plugins dotnet/nugetcpm . | 0 | — |
| D31 · IaC & Container Security | trivy | — | trivy config --format json --quiet . | 39 | artifacts/raw/trivy-config.json |
| D32 · Data Compliance (PII/GDPR) | semgrep | — | semgrep: not applicable — No personal data was found crossing a boundary the PII/GDPR ruleset checks — nothing written to a log or console sink, placed in a URL or query string, or persisted to browser storage. That is a clean result for the LEAK surface only: this ruleset detects personal data escaping, it does not inventory the personal data a repository holds, so it is not evidence that this repository has no personal-data surface. The personal-data map (Appendix C) and the C1-C5 compliance cards are what speak to that. semgrep could not parse 31 file(s) — `src/ApplicationCore/Entities/OrderAggregate/Events/OrderCreatedEvent.cs`, `src/ApplicationCore/Entities/OrderAggregate/Handlers/OrderCreatedHandler.cs`, `src/BlazorAdmin/Services/RoleManagementService.cs`, `src/BlazorAdmin/Services/UserManagementService.cs`, `src/Infrastructure/Identity/JwtSettingsValidator.cs`, … (+26 more) — so the PII/GDPR sweep did not cover the unparsed regions of them; rows reported elsewhere in those files are real. | 0 | — |
| D37 · Vulnerability-disclosure Policy | disclosure | — | disclosure: not applicable — No vulnerability-disclosure policy file found (SECURITY.md/.markdown/.rst/.txt at root or under .github/.forgejo/.gitea/docs, .well-known/security.txt). A coordinated-disclosure policy may live off-repo, so this is not evidenced rather than failed. | 0 | — |
| D40 · Network Egress Confinement | runtime-hardening | — | runtime-hardening: not applicable — No Kubernetes/orchestration workloads found in the repository manifests; network egress policy is a cluster-native control that may live at the platform/firewall layer, so there is nothing to assess here. | 0 | — |
| D41 · Kernel & Syscall Confinement | runtime-hardening | — | runtime-hardening: not applicable — No Kubernetes/orchestration workloads found in the repository manifests; seccomp/AppArmor/SELinux confinement is a workload-level control, so there is nothing to assess here. | 0 | — |
| D42 · Runtime Threat Enforcement | runtime-hardening | — | runtime-hardening: not applicable — No Kubernetes/orchestration workloads found in the repository manifests; runtime threat-detection and admission-control policy are cluster-level controls, so there is nothing to assess here. | 0 | — |
| D43 · Malicious Dependencies | osv-scanner | — | osv-scanner --format json --recursive --experimental-disable-plugins transitivedependency/requirements --experimental-disable-plugins dotnet/csproj --experimental-disable-plugins dotnet/nugetcpm . | 0 | — |
Appendix C — Personal-data map
Email — 8 field(s)
- User.Email src/BlazorAdmin/Models/User.cs:16
- UserDto.Email src/PublicApi/UserManagementEndpoints/UserDto.cs:9
- InputModel.Email src/Web/Areas/Identity/Pages/Account/Login.cshtml.cs:41
- InputModel.Email src/Web/Areas/Identity/Pages/Account/Register.cshtml.cs:43
- LoginViewModel.Email src/Web/ViewModels/Account/LoginViewModel.cs:9
- RegisterViewModel.Email src/Web/ViewModels/Account/RegisterViewModel.cs:10
- ResetPasswordViewModel.Email src/Web/ViewModels/Account/ResetPasswordViewModel.cs:9
- IndexViewModel.Email src/Web/ViewModels/Manage/IndexViewModel.cs:13
Phone — 3 field(s)
- User.PhoneNumber src/BlazorAdmin/Models/User.cs:18
- UserDto.PhoneNumber src/PublicApi/UserManagementEndpoints/UserDto.cs:11
- IndexViewModel.PhoneNumber src/Web/ViewModels/Manage/IndexViewModel.cs:17
Address — 1 field(s)
- Address.ZipCode src/ApplicationCore/Entities/OrderAggregate/Address.cs:13