kodlamaio-projects/nArchitecture

This release establishes the foundational architecture for a .NET 8 application, introducing a complete solution structure with distinct Application, Domain, and Infrastructure layers. It implements core security features, including user authentication, role-based access control via operation claims, and two-factor authentication support. The update also standardizes the codebase by migrating to the nArchitecture.Core framework, which brings generic repository patterns, soft-delete capabilities, and consistent DTO structures across the system.

The infrastructure layer now includes a new Cloudinary adapter for image uploads and deletions, registered as the default implementation for the ImageServiceBase interface. This enables users to store images in Cloudinary rather than a local or other cloud provider.

src/starterProject/Infrastructure · high confidence

New Entity Framework Core configuration classes have been added for the \EmailAuthenticator\, \OtpAuthenticator\, \RefreshToken\, \User\, and \UserOperationClaim\ entities, mapping their database schema and relationships. Additionally, the \OperationClaim\ entity configuration now includes seed data for administrative and feature-specific operation claims, establishing the initial set of permissions for the system.

src/starterProject/Persistence/EntityConfigurations · high confidence

Introduces a new GetById query for retrieving UserOperationClaim entities by their unique identifier. The implementation includes the query class, response DTO, and a MediatR handler that fetches the record via the repository, applies business rules, and maps the result to the response object.

src/starterProject/Application/Features/UserOperationClaims/Queries/GetById · high confidence

A new GetById query and its corresponding response model have been added for operation claims. This introduces a read operation that retrieves a single operation claim by its ID, utilizing the nArchitecture.Core application pipelines for authorization and mapping. The implementation relies on the IOperationClaimRepository and OperationClaimBusinessRules to fetch and validate the claim, returning a DTO containing the claim's ID and name.

src/starterProject/Application/Features/OperationClaims/Queries/GetById · high confidence

A new service layer for the UserOperationClaim entity has been introduced, providing standard CRUD operations (Get, GetList, Add, Update, Delete) via the IUserOperationClaimService interface and UserUserOperationClaimManager implementation. This adds the capability to manage user-operation claim records, including business rule validation during insert and update operations.

src/starterProject/Application/Services/UserOperationClaims · medium confidence

Users can now create new operation claims through a new command handler and associated validator. The implementation includes the command class, a FluentValidation validator enforcing a non-empty name with a minimum length of 2 characters, and a response object returning the new claim's ID and name.

src/starterProject/Application/Features/OperationClaims/Commands/Create · high confidence

Added new commands to enable and verify email and OTP (One-Time Password) two-factor authentication methods. Users can now enable email-based and OTP-based authenticators, and verify them via activation keys or codes, integrating with existing login and token refresh flows.

src/starterProject/Application/Features/Auth/Commands · high confidence

Introduced new service interfaces and implementations for managing OperationClaims and Users. Each service provides standard CRUD operations (GetAsync, GetListAsync, AddAsync, UpdateAsync, DeleteAsync) that delegate to their respective repositories and apply specific business rules (e.g., checking for duplicate names or emails) before persisting changes. These services are part of the application layer, utilizing the NArchitecture.Core framework for persistence and paging.

src/starterProject/Application/Services/OperationClaims, src/starterProject/Application/Services/UsersService · high confidence

Users can now update existing operation claims through a new command handler that validates input, checks for name conflicts, and persists changes via the repository. The update flow includes a validator enforcing a non-empty name with a minimum length of 2 characters, and the command implements security role checks to ensure only authorized users can modify operation claims.

src/starterProject/Application/Features/OperationClaims/Commands/Update · high confidence

Users can now create a new user operation claim through a new command handler that validates the user ID and operation claim ID, then maps and persists the claim using the repository and business rules.

src/starterProject/Application/Features/UserOperationClaims/Commands/Create · high confidence

Users can now retrieve a paginated list of user operation claims. This change introduces a new query and DTO for listing user operation claims, supporting pagination via PageIndex and PageSize, and enforcing role-based access control for read operations.

src/starterProject/Application/Features/UserOperationClaims/Queries/GetList · high confidence

The application now supports retrieving a user's details by their unique identifier. This change introduces a new query handler that fetches a user record from the repository, validates the user's existence, and maps the result to a response object containing the user's ID, name, email, and status.

src/starterProject/Application/Features/Users/Queries/GetById · high confidence

The user update workflow now includes two distinct command handlers: a standard update command that modifies user profile details and password, and a specialized update-from-auth command that additionally validates the current password, enforces strong password requirements for new passwords, and returns a JWT access token upon successful update. This introduces a new authentication-aware update path that automatically issues a new token after password changes, while the standard update path remains separate.

src/starterProject/Application/Features/Users/Commands/UpdateFromAuth · high confidence

Introduced the AuthenticatorService, which provides methods for creating and verifying email and OTP (One-Time Password) authenticators. The service handles sending authentication codes via email and verifying user-provided codes for both email and OTP-based authentication flows.

src/starterProject/Application/Services/AuthenticatorService · high confidence

Introduced the CreateUserCommand, its corresponding validator, and the CreatedUserResponse DTO for the Users feature. The command handler now utilizes NArchitecture.Core for authorization and security utilities (HashingHelper) and applies business rules to ensure the email is unique before creating the user.

src/starterProject/Application/Features/Users/Commands/Create · high confidence

The AuthService location now contains the concrete AuthManager and its IAuthService interface, providing user authentication capabilities. The implementation handles creating and rotating access and refresh tokens using NArchitecture.Core.Security.JWT, mapping core security entities to domain models via AutoMapper, and managing token lifecycle (creation, revocation, and rotation) through repository interactions.

src/starterProject/Application/Services/AuthService · high confidence

The repository is initialized with a complete solution structure for a .NET 7 application, including a solution file, project references for Application, Domain, Persistence, WebAPI, and Infrastructure layers, and a test project. Developer experience is enhanced with an .editorconfig for consistent C\# formatting and code style rules, a .csharpierrc for CSharpier integration, and a .gitignore for IDE and build artifacts. The project also includes a README with usage and contribution instructions, a LICENSE file, and a JetBrains Rider settings file.

(repo-wide) · high confidence

The WebAPI project is initialized with a new \Program.cs\ that configures the ASP.NET Core pipeline, including JWT Bearer authentication, CORS, Swagger UI, and a database migration applier. The \PersistenceServiceRegistration\ sets up an in-memory database (\BaseDbContext\) and registers repository interfaces with their implementations. Configuration files (\appsettings.json\, \appsettings.Development.json\, \appsettings.Staging.json\) provide default settings for logging, caching, and security tokens. The \WebApiConfiguration\ class and related settings allow for API domain and allowed origins configuration.

src/starterProject/WebAPI · high confidence

Added AuthBusinessRules to enforce authentication validations, including checks for email and OTP authenticators, refresh token status, and user credentials. The new file implements business logic for verifying authenticators, ensuring users do not have conflicting authenticator types, and validating password hashes. Additionally, a MappingProfiles class was added to configure AutoMapper mappings for RefreshToken and RevokedTokenResponse entities.

src/starterProject/Application/Features/Auth/Rules · high confidence

Added a new mapping profile for UserOperationClaims that configures AutoMapper mappings between the domain entity and various command and response types, including Create, Update, Delete, GetById, and GetList operations, utilizing types from the NArchitecture.Core library.

src/starterProject/Application/Features/UserOperationClaims/Profiles · high confidence

A new UserBusinessRules class has been added to enforce user-related constraints, including checks for user existence, email uniqueness, and password matching. The implementation leverages the NArchitecture.Core framework for localization and exception handling, integrating with the existing repository layer to ensure data integrity during user operations.

src/starterProject/Application/Features/Users/Rules · high confidence

The WebAPI layer now includes new controllers to expose user, authentication, and operation claim management endpoints. The AuthController handles login, registration, token refresh, and two-factor authentication (email and OTP) flows. The UsersController provides CRUD operations for user management, including retrieving the current user's profile and updating user details. The OperationClaimsController and UserOperationClaimsController expose endpoints for managing system-wide operation claims and user-specific claim assignments, respectively. All controllers inherit from a new BaseController that provides shared functionality for IP address retrieval and user ID extraction.

src/starterProject/WebAPI/Controllers · high confidence

The application layer now includes an OperationClaimBusinessRules class that enforces validation for operation claims. It ensures that an operation claim exists when selected, that an ID is not duplicated, and that names are unique during creation and updates. The rules use a repository to check existence and a localization service to retrieve error messages, integrating with the nArchitecture.Core framework for exception handling and localization.

src/starterProject/Application/Features/OperationClaims/Rules · high confidence

A new UserOperationClaimBusinessRules class was added to enforce validation logic for user operation claims. The implementation includes checks to ensure claims exist or do not exist as appropriate, and prevents duplicate assignments for users. The rules utilize a repository for data access and a localization service to retrieve error messages, integrating with the NArchitecture.Core framework for exception handling and localization.

src/starterProject/Application/Features/UserOperationClaims/Rules · high confidence

The application now supports soft deletion of user operation claims. A new command handler in the Delete folder implements the logic to retrieve, validate, and mark a UserOperationClaim as deleted via the repository's DeleteAsync method, returning a DeletedUserOperationClaimResponse. This change introduces the infrastructure for non-permanent removal of claims, aligning with the project's move toward generic security entities and soft-delete patterns.

src/starterProject/Application/Features/UserOperationClaims/Commands/Delete · medium confidence

The application now supports soft deletion of operation claims. A new command handler in the OperationClaims feature calls a repository's DeleteAsync method, which triggers the new soft-delete behavior provided by the updated nArchitecture.Core packages. Users will see operation claims marked as deleted rather than permanently removed from the database.

src/starterProject/Application/Features/OperationClaims/Commands/Delete · high confidence

Users can now update existing user operation claims through a new command handler that validates input, checks business rules, and persists changes via the repository. The implementation includes the command, a FluentValidation validator ensuring UserId is present and OperationClaimId is positive, and a response DTO, all leveraging the nArchitecture.Core NuGet packages for authorization and mapping.

src/starterProject/Application/Features/UserOperationClaims/Commands/Update · medium confidence

The Application layer has been refactored to utilize the nArchitecture.Core NuGet packages, replacing previous implementations with standardized service registrations and behaviors. This includes the addition of YAML-based localization support, the integration of core application pipelines (authorization, caching, logging, validation, and transaction scopes) via MediatR, and the registration of security and mail services. Additionally, a base class for image service handling has been introduced to manage file uploads, updates, and deletions with format validation.

src/starterProject/Application · medium confidence

The application now defines explicit constants for operation claims (Admin, Read, Write, Create, Update, Delete) and their associated error messages (NotExists, AlreadyExists) in the OperationClaims feature. This change introduces new static classes to centralize claim names and localization section names, which will be used to manage access control and error handling for operation claims.

src/starterProject/Application/Features/OperationClaims/Constants · medium confidence

Added new constants files for the authentication feature: AuthMessages.cs defines string keys for various authentication and user-related error messages (e.g., missing authenticator, invalid tokens, user not found), while AuthOperationClaims.cs defines operation claim keys for Admin, Write, Read, and RevokeToken permissions. These changes provide the foundational message and claim definitions for the auth feature.

src/starterProject/Application/Features/Auth/Constants · high confidence

A new BaseDbContext class has been added to the persistence layer, providing a shared foundation for database interactions. It configures standard security-related entities (such as users, authenticators, and operation claims) and applies entity configurations from the current assembly, establishing the default database schema structure.

src/starterProject/Persistence/Contexts · high confidence

Added new domain entities to support application security, including User, OperationClaim, UserOperationClaim, RefreshToken, OtpAuthenticator, and EmailAuthenticator. These classes extend core security entities from the NArchitecture.Core.Security.Entities namespace, establishing the data model for user authentication and authorization within the Domain layer.

Domain · high confidence

Added new constants files defining the localized message keys (UserOperationClaimNotExists, UserOperationClaimAlreadyExists) and the CRUD operation claim names (Admin, Read, Write, Create, Update, Delete) for the UserOperationClaims feature. This establishes the string constants used for validation and authorization within this feature.

src/starterProject/Application/Features/UserOperationClaims/Constants · high confidence

The application now supports soft deletion of users. A new DeleteUserCommand and DeletedUserResponse have been added to the user features, allowing users to be marked as deleted rather than permanently removed from the database. This change aligns with the introduction of soft delete functionality across the system.

src/starterProject/Application/Features/Users/Commands/Delete · high confidence

A new ITranslateService interface is added to define the contract for translation functionality, exposing a TranslateAsync method that accepts source text and optional target and source language parameters.

src/starterProject/Application/Services/TranslateService · high confidence

Added UsersMessages.cs and UsersOperationClaims.cs to define localized error messages (e.g., UserDontExists, PasswordDontMatch) and operation claims (Admin, Read, Write, Create, Update, Delete) for the Users feature. This provides a centralized location for user-related constants, supporting the broader refactor to use application security entities and generic security entities as noted in the commit messages.

src/starterProject/Application/Features/Users/Constants · medium confidence

Repository classes in the persistence layer have been updated to inherit from a generic \EfRepositoryBase\ that includes the entity's identifier type as a generic parameter. This change aligns the \Persistence\ layer with the \nArchitecture.Core\ NuGet packages, standardizing how data access is implemented for entities such as \User\, \RefreshToken\, and \OperationClaim\.

src/starterProject/Persistence/Repositories · medium confidence

Repository interfaces for authentication, user, and claim entities (including IEmailAuthenticatorRepository, IOperationClaimRepository, IOtpAuthenticatorRepository, IRefreshTokenRepository, IUserOperationClaimRepository, and IUserRepository) now inherit from NArchitecture.Core.Persistence.Repositories.IAsyncRepository and IRepository. This change standardizes the data access layer by replacing previous implementations with generic repository patterns provided by the NArchitecture.Core library, ensuring consistent asynchronous query and command operations across the application.

src/starterProject/Application/Services/Repositories · medium confidence

The list query implementations for OperationClaims and Users have been refactored to use the shared nArchitecture.Core NuGet packages. Both queries now utilize the generic security entities and application security entities from the core library, replacing previous custom implementations. This change ensures consistent pagination handling via the core's PageRequest/PageIndex model and applies standardized DTO structures for listing operations.

src/starterProject/Application/Features/OperationClaims/Queries/GetList, src/starterProject/Application/Features/Users/Queries/GetList · medium confidence

The mapping profiles for OperationClaims and Users have been updated to use the shared response and command types from the NArchitecture.Core library, ensuring consistent DTO structures across the application.

src/starterProject/Application/Features/OperationClaims/Profiles, src/starterProject/Application/Features/Users/Profiles · medium confidence

Add unit tests for the login command; Added unit tests for user and authentication service registrations.

The project has been upgraded to target .NET 8.0 across all project files. Additionally, the solution now references the new NArchitecture.Core NuGet packages (such as NArchitecture.Core.Application, NArchitecture.Core.Security, and others) to replace previous dependencies, and includes updated versions of Microsoft.EntityFrameworkCore and related libraries.

(dependencies) · high confidence

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

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

• Code Health 84 → 84 (-0.1)
• Architecture 92 → 92 (+0.0)
• Maturity 53 → 53 (+0.0)
• Readiness 42 → 41 (-1.1)
• Security 19 → 23 (+4.4)

• Bounded contexts not declared
• Duplicated block (5 lines × 2) (src/starterProject/Application/Features/Users/Commands/Create/CreateUserCommandValidator.cs)
• High CVE: System.Text.Json 8.0.0
• High CVE: System.Text.Json 8.0.0
• High: security finding (details withheld)
• High: security finding (details withheld)
• Low CVE: Microsoft.Identity.Client 4.56.0
• Medium CVE: Azure.Identity 1.10.3
• Medium CVE: Azure.Identity 1.10.3
• Medium CVE: BouncyCastle.Cryptography 2.3.0
• Medium CVE: BouncyCastle.Cryptography 2.3.0
• Medium CVE: BouncyCastle.Cryptography 2.3.0
• Medium CVE: MimeKit 4.4.0
• No exposed public API
• dormant codebase — no living knowledge left to concentrate
• redundant comment (src/starterProject/WebAPI/Controllers/BaseController.cs)

• Documentation: no installation or build instructions (README.md)
• Documentation: no usage examples (README.md)
• Duplicated block (10 lines × 3) (src/starterProject/Application/Features/OperationClaims/Constants/OperationClaimsOperationClaims.cs)
• Duplicated block (14 lines × 4) (src/starterProject/Application/Features/Users/Commands/Create/CreatedUserResponse.cs)
• Duplicated block (6 lines × 2) (src/starterProject/Application/Features/Users/Commands/Create/CreateUserCommandValidator.cs)
• Duplicated block (8 lines × 6) (src/starterProject/Persistence/EntityConfigurations/EmailAuthenticatorConfiguration.cs)
• Duplicated block (9 lines × 3) (src/starterProject/Persistence/EntityConfigurations/EmailAuthenticatorConfiguration.cs)
• High CVE: System.Text.Json 8.0.0
• High: security finding (details withheld)
• High: security finding (details withheld)
• Inconsistent naming for the same logical operation: one method uses the imperative verb 'Delete' while the other uses the noun-based query pattern 'Get'. The AuthManager method deletes tokens, while the Repository method retrieves them. While they are distinct operations (one is a service action, one is a data access query), the naming convention for the repository method GetOldRefreshTokensAsync implies it returns the old tokens, whereas the manager method DeleteOldRefreshTokens implies it removes them. If the manager relies on the repository to find the tokens to delete, the repository name is correct. However, if there is a separate method in the repository that performs the deletion, it should likely be named DeleteOldRefreshTokensAsync to match the manager's intent, or the manager should be named DeleteOldRefreshTokensUsing to clarify it's a composite action. More critically, looking at UserBusinessRules.UserEmailShouldNotExistsWhenInsert vs AuthBusinessRules.UserEmailShouldBeNotExists, the phrasing 'ShouldNotExists' vs 'ShouldBeNotExists' is inconsistent.
• Inconsistent verb usage between service layer and repository layer for related operations. AuthManager uses 'Delete' while RefreshTokenRepository uses 'Get'. If AuthManager calls GetOldRefreshTokensAsync to fetch the tokens and then deletes them, the naming is technically correct but semantically disjointed. If RefreshTokenRepository had a method to delete them, it should be DeleteOldRefreshTokensAsync.
• Low coverage: src/starterProject/Application/ApplicationServiceRegistration.cs (src/starterProject/Application/ApplicationServiceRegistration.cs)
• Low coverage: src/starterProject/Application/Features/Auth/Commands/EnableEmailAuthenticator/EnableEmailAuthenticatorCommand.cs (src/starterProject/Application/Features/Auth/Commands/EnableEmailAuthenticator/EnableEmailAuthenticatorCommand.cs)
• Low coverage: src/starterProject/Application/Features/Auth/Commands/EnableOtpAuthenticator/EnableOtpAuthenticatorCommand.cs (src/starterProject/Application/Features/Auth/Commands/EnableOtpAuthenticator/EnableOtpAuthenticatorCommand.cs)
• Low coverage: src/starterProject/Application/Features/Auth/Commands/EnableOtpAuthenticator/EnabledOtpAuthenticatorResponse.cs (src/starterProject/Application/Features/Auth/Commands/EnableOtpAuthenticator/EnabledOtpAuthenticatorResponse.cs)
• Low coverage: src/starterProject/Application/Features/Auth/Commands/Login/LoggedResponse.cs (src/starterProject/Application/Features/Auth/Commands/Login/LoggedResponse.cs)
• Low coverage: src/starterProject/Application/Features/Auth/Commands/RefreshToken/RefreshTokenCommand.cs (src/starterProject/Application/Features/Auth/Commands/RefreshToken/RefreshTokenCommand.cs)
• Low coverage: src/starterProject/Application/Features/Auth/Commands/RefreshToken/RefreshedTokensResponse.cs (src/starterProject/Application/Features/Auth/Commands/RefreshToken/RefreshedTokensResponse.cs)
• Low coverage: src/starterProject/Application/Features/Auth/Commands/Register/RegisterCommand.cs (src/starterProject/Application/Features/Auth/Commands/Register/RegisterCommand.cs)
• …and 45 more

• Unchanged — 25 HTTP endpoints

• Unchanged — 3 containers · 1 contexts · 0 edges

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

kodlamaio-projects/nArchitecture 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.