Jackpieking/ASPNET_CORE_VSA_Template

This system is an ASP.NET Core API template implementing Vertical Slice Architecture for managing todo lists and tasks. It provides a complete set of features including user authentication, task list creation, and granular task operations such as updating content, toggling completion status, and managing due dates. The application supports cursor-based pagination for retrieving tasks and utilizes PostgreSQL, Redis, and JWT-based security for data persistence and access control.

A new feature module template has been added to the CLI scaffolding system. This template provides a complete, ready-to-use structure for a new feature, including a business logic service, data access repository, request/response models, HTTP response mapping, and dependency injection registration. It serves as a starting point for developers to implement new features following the established architectural patterns.

(repo-wide) · high confidence

This change introduces the F10 feature, exposing a new HTTP GET endpoint at 'f10/list/cursor/{TodoTaskListId:required}' that retrieves a paginated list of todo task lists. The implementation includes a service layer that validates the existence of the specified list and fetches records using cursor-based pagination (returning a 'NextCursor' for subsequent requests). The feature is secured via the 'DefaultAuthorizationRequirement' policy and includes input validation to ensure 'NumberOfRecord' is between 1 and 10. It also defines the necessary data models, repository interface for database access, and dependency registration to wire the components together.

Src/Core/F10 · high confidence

The FBaseApi and FConfig modules now include strongly-typed configuration classes for application settings. This adds AppDbContextOption for database context settings, AspNetCoreIdentityOption for identity and authentication policies, JwtAuthenticationOption for JWT validation settings, NSwagOption for API documentation configuration, and SnowflakeIdOption for distributed ID generation. These options provide a structured way to configure core infrastructure components.

Src/Base · high confidence

The F14 feature now exposes a new endpoint at 'f14/list/{TodoTaskListId}/task/cursor/{TodoTaskId}' that retrieves completed todo tasks using cursor-based pagination. Users can request a specific number of records via the 'n' query parameter, and the response includes a 'NextCursor' ID to fetch subsequent pages. The service validates the existence of the task list and optional task ID, returning appropriate 404 errors if not found, and returns a 400 error for validation failures (e.g., negative IDs or zero record count).

Src/Core/F14 · high confidence

Introduces a new template for the presentation tier of feature modules, providing a structured ASP.NET Core endpoint implementation. This includes an \Endpoint\ class that handles HTTP POST requests, integrates with business logic services, and utilizes custom action filters for state management (\SetStateBagFilter\) and request validation (\ValidationFilter\). The template also supplies the necessary data transfer objects (\Request\, \Response\) and validation profiles to ensure consistent API contract enforcement across generated features.

Template/Feature/Presentation · high confidence

New PowerShell and Bash scripts have been added to the Scripts directory to streamline the development workflow. These include build, clean, init, publish, run, and test commands for both Windows and Linux/macOS environments. The scripts automatically locate the solution file, read configuration from a .env file, and execute standard .NET CLI commands. Notably, the build and run scripts now integrate C\# formatting via Csharpier, and the test script generates HTML code coverage reports using ReportGenerator.

Scripts · high confidence

The FA1 module now includes its foundational data layer, introducing a PostgreSQL-backed Entity Framework Core setup with a dedicated 'todo' schema and case-insensitive collation support. This change adds the core domain entities for a todo-list application (including users, task lists, tasks, and steps) alongside ASP.NET Core Identity entities, along with their corresponding EF Core configurations and an initial database migration to establish the required tables and relationships.

Src/External · high confidence

This change introduces the foundational structure for an ASP.NET Core project based on Vertical Slice Architecture, targeting .NET 8.0 (SDK 8.0.404). It establishes a multi-assembly solution with core features (F1–F21) and external features (FA1–FA4), managed via centralized build properties and a custom assembly configuration file. The release includes automation scripts for initialization, building, cleaning, publishing, and testing, alongside Docker infrastructure for Postgres, Redis, and PgBouncer. It also sets up development tooling with C\# formatting rules, Git attributes, and NuGet security auditing, while switching the project license from Apache 2.0 to MIT.

(repo-wide) · high confidence

The Entry application now uses a dynamic assembly-based service registration center that loads and registers services from external, core, and entry assemblies defined in an 'app-assembly.json' file, replacing static registration. Additionally, Swagger UI is enabled for Development, Staging, and Production environments, allowing API documentation access at the root path.

Src/Entry · high confidence

This change adds the core implementation for a password reset feature in the F4 module. It introduces a new HTTP endpoint (POST /f4) that accepts an email address, validates it, and generates a secure password reset token. The service layer handles the business logic by looking up the user, creating a reset token record in the database, and issuing a JWT with a specific purpose claim. The response returns this JWT to the client, which can be used to complete the password reset flow. Constants define a 15-minute expiration for these tokens.

Src/Core/F4 · high confidence

This change adds the foundational infrastructure for application security and identity management within the FCommon library. It introduces JWT access token generation and expiration checking, along with a default authorization handler that validates user authentication, token expiry, and specific token purposes (e.g., 'user\_in\_app'). It also provides a Snowflake-based distributed ID generator for unique identifier creation and a secure refresh token generator. These components are wired together via a service registration class that configures JWT validation parameters and authorization policies, establishing the baseline security model for the application.

Src/Core/FCommon · high confidence

A new HTTP DELETE endpoint at \f8/list/{TodoTaskListId}\ has been added, allowing users to remove a specific todo list. The implementation ensures that deleting a list also cascades to remove all its associated tasks and task steps within a single database transaction. The service validates that the list exists before attempting removal and returns specific HTTP status codes (404 if the list is not found, 400 for validation errors, 500 for server errors) to indicate the outcome of the operation.

Src/Core/F8 · high confidence

This change introduces two new API capabilities in the F1 and F2 modules. The F1 module adds a user login endpoint that authenticates users via email and password, issuing JWT access tokens and refresh tokens (with configurable durations for 'Remember Me' vs standard sessions) and handling specific outcomes like user not found, incorrect password, or temporary lockout. The F2 module adds a todo-list detail retrieval endpoint that fetches a list by ID, returning the list name or a 'list not found' error, and requires authorization via the DefaultAuthorizationRequirement policy. Both modules include their respective business logic, data access repositories, request/response models, validation filters, and dependency registration centers.

Src/Core/F1 · high confidence

This change introduces the F11 feature, enabling users to create new todo tasks within an existing list. The implementation includes a new HTTP POST endpoint at 'f11' that accepts a task content and list ID, validates the input, and persists the new task to the database via a repository layer. It also defines the necessary request/response models, business logic service, and dependency registrations to support this capability.

Src/Core/F11 · high confidence

This change introduces the F12 feature, enabling users to delete a specific todo task via a DELETE endpoint at 'f12/task/{TodoTaskId}'. The implementation includes a service layer that verifies the task's existence before removal, a repository layer that executes a database transaction to delete both the task and its associated steps, and presentation components (Endpoint, Filters, Mappers) that handle request validation, authorization, and HTTP response mapping.

Src/Core/F12 · high confidence

This change introduces the F15 feature, which allows users to fetch the details of a specific todo task via a GET endpoint at 'f15/task/{TodoTaskId}'. The implementation includes a new API endpoint that validates the task ID, retrieves the task data (including content, due date, completion status, and notes) from the database, and returns the information in a structured JSON response. If the specified task does not exist, the service returns a 404 Not Found error.

Src/Core/F15 · high confidence

This change introduces the F16 feature, allowing users to add or remove a specific todo task from their 'My Day' list via a new POST endpoint at 'f16'. The implementation includes a service layer that validates the task's existence and updates the 'IsInMyDay' status in the database, supported by request/response models, a repository for data access, and validation filters to ensure the task ID is valid.

Src/Core/F16 · high confidence

This change introduces the F17 feature, allowing users to mark a todo task as completed or uncompleted via a POST request to the 'f17' endpoint. The implementation includes a new API endpoint that accepts a task ID and a completion flag, validates the input (ensuring the task ID is non-negative), and updates the task's status in the database using Entity Framework Core with transactional safety. The service layer checks for task existence before attempting the update, returning appropriate HTTP status codes (200, 400, 404, 500) based on the outcome.

Src/Core/F17 · high confidence

This change introduces the F18 feature, allowing users to mark or unmark a specific todo task as important via a POST request to the 'f18' endpoint. The implementation includes a new API endpoint that accepts a task ID and a boolean flag, validates the input, and updates the task's importance status in the database using a transactional repository layer. It also defines the necessary request/response models, constants, and dependency registrations to support this capability.

Src/Core/F18 · high confidence

This change introduces the F20 feature, which allows users to update the note associated with an existing todo task. The implementation includes a new HTTP POST endpoint at the 'f20' path that accepts a task ID and a note string. The service validates that the task exists before attempting to update it, returning a 404 if the task is not found, and handles database updates with transactional integrity. Input validation ensures the task ID is non-negative and the note is non-empty and within the allowed length.

Src/Core/F20 · high confidence

This change introduces the F6 feature, providing a new POST endpoint at the 'f6' path that allows authenticated users to refresh their access tokens. The implementation includes a business service that validates the existing refresh token against the database, generates a new JWT access token with a 60-minute duration, and returns both the new access token and the original refresh token in the response. The feature is supported by a repository layer for database operations, authorization filters to ensure the user's current access token is expired, and validation filters to check the incoming refresh token format.

Src/Core/F6 · high confidence

This change introduces the F7 feature, enabling users to create new task todo lists via a POST endpoint at 'f7'. The implementation includes a new API endpoint that accepts a list name and user ID, validates the input, and persists the new list to the database. It also defines the necessary request/response models, business logic for list creation, data access via a repository, and HTTP response mapping to handle success and error states.

Src/Core/F7 · high confidence

This change introduces the F9 feature, allowing users to update the name of an existing task todo list. The implementation includes a new HTTP POST endpoint at 'f9' that accepts a list ID and a new name, validates the input, and persists the change to the database. The feature handles specific scenarios such as returning a 404 if the list does not exist, 400 for validation errors, and 500 for server errors, while ensuring transactional integrity during the update process.

Src/Core/F9 · high confidence

This change introduces a new API endpoint at \f13/list/{TodoTaskListId}/task/cursor/{TodoTaskId}\ that retrieves uncompleted todo tasks using cursor-based pagination. The implementation includes a new service layer that queries the database for tasks belonging to a specific list, filtering by a starting task ID to support efficient pagination. The response includes a \NextCursor\ field containing the ID of the last task in the current page, allowing clients to request subsequent pages. The endpoint enforces validation rules ensuring that list and task IDs are non-negative and the record count is positive, and returns specific HTTP 404 errors if the task list or the starting task is not found.

Src/Core/F13 · high confidence

This change introduces the F21 feature, allowing users to update the due date of an existing todo task. The implementation adds a new HTTP POST endpoint at 'f21' that accepts a task ID and a new due date. The service validates that the task exists and then persists the updated due date to the database within a transaction. Users will receive a 200 OK response on success, a 404 Not Found if the task ID does not exist, or a 400 Bad Request if the input validation fails.

Src/Core/F21 · high confidence

A new F19 feature has been added that allows users to update the content of an existing todo task. The implementation includes a POST endpoint at the 'f19' path, which accepts a task ID and new content. The service validates that the task exists and then updates the content in the database using a transactional strategy. The feature includes input validation (ensuring the task ID is non-negative and content is not empty and within length limits) and returns specific HTTP status codes for success, validation failures, task not found, or server errors.

Src/Core/F19 · high confidence

This change introduces a new password reset feature for the F5 service. It adds a POST endpoint at 'f5' that accepts a new password, validates it against configured identity rules, and verifies the provided reset token. The implementation includes a business service to orchestrate the reset, a data access repository to interact with the user database (using Entity Framework Core and IdentityUserTokenEntity), and presentation filters for authorization (checking JWT claims like purpose and expiration) and validation. It also defines request/response models, constants for error codes (e.g., TOKEN\_DOES\_NOT\_EXIST, PASSWORD\_IS\_INVALID), and a mapper to translate internal responses to HTTP status codes.

Src/Core/F5 · high confidence

The F3 module now exposes a POST endpoint at 'f3' that allows users to register new accounts. The flow validates the email format and password strength, checks for existing emails, and creates a new Identity user along with additional profile information in the database. It returns specific HTTP status codes (400, 409, 422, 500) for validation failures, duplicate emails, invalid passwords, or server errors, and 200 on success.

Src/Core/F3 · high confidence

The AppInfrastructure module has been established (renamed from RequiredServiceDocker) to manage the application's data and caching layers via Docker. It provides a docker-compose setup that runs Postgres 17.2, Pgbouncer 1.23.1, and Redis 7.4.2. The configuration includes specific environment variables for database credentials and ports, memory limits for each service, and a custom Redis ACL file to enforce user permissions.

AppInfrastructure · high confidence

The project now uses a central Directory.Packages.props file to manage dependency versions, establishing a baseline for key libraries including ASP.NET Core Identity and JWT Bearer authentication (8.0.11), Entity Framework Core and its PostgreSQL provider (9.0.x), NSwag (14.2.0), and SnowflakeGenerator (2.0.0). This change standardizes how external packages are referenced across the solution's base, core, and external modules.

(dependencies) · high confidence

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

• CAI 49 → 49 (+0.7)
• Rubric changed (rubric-2026.08.18 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 76 → 76 (-0.2)
• Architecture 94 → 94 (+0.1)
• Maturity 55 → 58 (+2.1)
• Readiness 32 → 30 (-2.5)
• Security 62 → 71 (+8.9)

• Bounded contexts not declared
• LLM evaluation failed
• No exposed public API
• Response models are named inconsistently. Some use 'AppResponseModel' in the Models namespace, while others use 'Response' or 'BodyDto' in the Presentation namespace. This suggests a lack of consistent layering or naming convention for response objects.
• The 'SetStateBag' filter is implemented in multiple modules (F5, F6, F9, F11, F14, F19, F20) with potentially different implementations. This suggests a lack of shared base class or interface for this common functionality.
• The term 'HttpResponseMapper' is used for classes that appear to handle HTTP responses or mapping, but the naming is inconsistent with the broader codebase which uses 'Response' or 'Dto' for response models. More critically, some mappers implement 'Init' while others implement 'Get', suggesting different responsibilities or patterns for the same concept.
• The term 'RefreshTokenModel' is used in multiple modules (F1, F6), but the structure and usage might differ. Additionally, 'RefreshToken' is also used in FConfig.NSwagOption.DocOption.AuthOption.BearerOption.Type, which is a configuration, not a model.
• There is a mix of 'AppRequestModel' and 'Request' for request models. Some modules use 'AppRequestModel' in the Models namespace, while others use 'Request' in the Presentation namespace. This creates confusion about whether these are the same concept.
• single-maintainer — knowledge-concentration (bus factor) risk

• Documentation: no contributor guidance
• Documentation: no installation or build instructions
• Documentation: no installation or build instructions (README.md)
• Documentation: no project overview
• Documentation: no usage examples
• Documentation: no usage examples (README.md)
• Duplicated block (10 lines × 2) (Src/Core/F13/Presentation/Filters/Validation/ValidationProfile.cs)
• Duplicated block (11 lines × 9) (Src/Core/F13/Mapper/HttpResponseMapper.cs)
• Duplicated block (11–37 lines × 9) (Src/Core/F13/Mapper/HttpResponseMapper.cs)
• Duplicated block (14–24 lines × 8) (Src/Core/F13/Mapper/HttpResponseMapper.cs)
• Duplicated block (16 lines × 3) (Src/Core/F14/Models/AppResponseModel.cs)
• Duplicated block (16 lines × 3) (Src/Core/F15/Models/AppResponseModel.cs)
• Duplicated block (17 lines × 2) (Src/Core/F8/DataAccess/Repository.cs)
• Duplicated block (18 lines × 3) (Src/Core/F13/Models/AppResponseModel.cs)
• Duplicated block (18 lines × 7) (Src/Core/F12/DataAccess/Repository.cs)
• Duplicated block (18–19 lines × 6) (Src/Core/F16/DataAccess/Repository.cs)
• Duplicated block (19 lines × 21) (Src/Core/F1/Presentation/Filters/Validation/ValidationFilter.cs)
• Duplicated block (19–20 lines × 3) (Src/Core/F16/DataAccess/Repository.cs)
• Duplicated block (20 lines × 19) (Src/Core/F1/RegistrationCenter.cs)
• Duplicated block (20 lines × 2) (Src/Core/F6/Presentation/Filters/Authorization/AuthorizationRequirementHandler.cs)
• …and 93 more

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

Jackpieking/ASPNET_CORE_VSA_Template 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.