Tillman32/CleanArchitecture

This system is a Clean Architecture-based blog application featuring both a server-side web interface and an offline-capable Blazor WebAssembly client. It provides full CRUD capabilities for managing articles and categories, utilizing a generic repository pattern for data access. The architecture supports both database-driven and local storage-based data persistence, enabling the application to function entirely on the client side when offline.

The application now includes a complete set of Razor Pages for managing and displaying articles. Users can view a list of articles on the home page, read individual articles, and create new articles with title, content, and image uploads. The update also introduces an 'About' page explaining the project's architecture, a standard error page, and the foundational layout and configuration files required to run the web application.

src/CleanArchitecture.ClientWeb · high confidence

Introduced the core data layer for the application, including entity classes (ArticleEntity, ArticleCategoryEntity) and their corresponding DTOs (ArticleDTO, ArticleCategoryDTO) with fields for title, content, tags, and category association. A generic repository interface (IGenericRepository) was added to standardize data access operations like GetAll, GetById, Create, Update, and Delete. Service layers (ArticleService, ArticleCategoryService) were implemented to handle business logic, including listing articles and categories, managing drafts, and mapping between entities and DTOs using AutoMapper.

src/CleanArchitecture.Core · high confidence

The infrastructure layer now includes an EF Core ApplicationDbContext for managing database connections, a generic repository (GenericRepository) that uses IDbContextFactory for data access, and an NLog-based logger (NLogLogger) implementing the core logging interface. These components provide the foundational data access and logging capabilities for the application.

src/CleanArchitecture.Infrastructure · high confidence

The repository was initialized with a complete project structure, including a solution file defining the CleanArchitecture modules (Core, Infrastructure, ClientWeb, Test, and WASM), along with essential documentation files (README, TODOS, CLAUDE.md) and licensing. This establishes the baseline architecture and development guidelines for the application.

(repo-wide) · high confidence

The Blazor WebAssembly application now includes a complete offline-capable data layer using local storage. A new \LocalStorageRepository\ implementation persists data in the browser's local storage, enabling full offline functionality. The app initializes with a set of pre-seeded articles and categories via a \LocalStorageDbInitializer\, ensuring the application has content to display immediately. This replaces any previous reliance on server-side databases for the WASM client, allowing the blog to function entirely on the client side.

src/CleanArchitecture.WASM · high confidence

Added unit tests for the IGenericRepository interface, covering create, read, update, and delete operations using a mock repository and a simple entity class.

src/CleanArchitecture.Test · high confidence

All project files have been upgraded to target .NET 10.0. Key dependencies have been updated, including AutoMapper (12.0.1 → 15.1.1) and Microsoft.EntityFrameworkCore (10.0.0).

(dependencies) · medium confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 40 → 41 (+1.1)
• Rubric changed (rubric-2026.08.18 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 74 → 74 (+0.0)
• Architecture 81 → 81 (+0.0)
• Maturity 62 → 67 (+5.0)
• Readiness 39 → 37 (-2.1)
• Security 30 → 38 (+7.9)
• Accessibility 45 → 35 (-10.1)

• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• No exposed public API
• Off-boarding risk: anonymized user #1
• The motivation section is strong but it does not explain what exactly each N-Tier layer provides or how to consume the web API from a client application. (README.md)
• The motivation section mentions Uncle Bob but no link to his Clean Architecture blog or the referenced outline. (README.md)

• Documentation: no installation or build instructions (README.md)
• Documentation: no usage examples (README.md)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• No dependency advisory monitoring
• The navigation property in the Entity is named 'Category', but the corresponding property in the DTO is also named 'Category'. While this is often acceptable for 1:1 mappings, in a Clean Architecture context where DTOs are often flattened or transformed, having a navigation object in the DTO (implied by the name 'Category' rather than 'CategoryId' or 'CategoryName') can be ambiguous. However, looking at the presence of 'CategoryId' in both Entity and DTO, it suggests 'Category' might be intended as a navigation/reference. If 'Category' in DTO is meant to be the full object, it's consistent. If it's meant to be the ID, it's inconsistent with 'CategoryId'. Given 'CategoryId' exists, 'Category' in DTO is likely a redundant or confusingly named property if it holds the same data, or a navigation property if it holds the object. A more standard convention for DTOs is to use the ID property for relationships unless a specific DTO for the related entity is used. However, without seeing the implementation, this is a potential semantic ambiguity rather than a strict naming inconsistency. Let's look for clearer inconsistencies.
• …and 1 more

• Unchanged — 2 containers · 0 contexts · 0 edges

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

Tillman32/CleanArchitecture was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.