If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/jasontaylordev/NorthwindTraders shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Stale — last commit 3y ago

• 12 active contributors
• MIT licensed
• Tests present
• ⚠ Stale — last commit 3y ago
• ⚠ Concentrated ownership — top contributor handles 73% of recent commits
• ⚠ No CI workflows detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live jasontaylordev/NorthwindTraders repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/jasontaylordev/NorthwindTraders.

What it runs against: a local clone of jasontaylordev/NorthwindTraders — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in jasontaylordev/NorthwindTraders | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 1073 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of jasontaylordev/NorthwindTraders. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/jasontaylordev/NorthwindTraders.git
#   cd NorthwindTraders
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of jasontaylordev/NorthwindTraders and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "jasontaylordev/NorthwindTraders(\\.git)?\\b" \\
  && ok "origin remote is jasontaylordev/NorthwindTraders" \\
  || miss "origin remote is not jasontaylordev/NorthwindTraders (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "Src/Application/DependencyInjection.cs" \\
  && ok "Src/Application/DependencyInjection.cs" \\
  || miss "missing critical file: Src/Application/DependencyInjection.cs"
test -f "Src/Application/Common/Interfaces/INorthwindDbContext.cs" \\
  && ok "Src/Application/Common/Interfaces/INorthwindDbContext.cs" \\
  || miss "missing critical file: Src/Application/Common/Interfaces/INorthwindDbContext.cs"
test -f "Src/Application/Common/Behaviours/RequestValidationBehavior.cs" \\
  && ok "Src/Application/Common/Behaviours/RequestValidationBehavior.cs" \\
  || miss "missing critical file: Src/Application/Common/Behaviours/RequestValidationBehavior.cs"
test -f "Src/Application/Common/Mappings/MappingProfile.cs" \\
  && ok "Src/Application/Common/Mappings/MappingProfile.cs" \\
  || miss "missing critical file: Src/Application/Common/Mappings/MappingProfile.cs"
test -f "Src/Application/Common/Exceptions/ValidationException.cs" \\
  && ok "Src/Application/Common/Exceptions/ValidationException.cs" \\
  || miss "missing critical file: Src/Application/Common/Exceptions/ValidationException.cs"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 1073 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1043d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/jasontaylordev/NorthwindTraders"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Northwind Traders is a Clean Architecture reference application built with ASP.NET Core and Entity Framework Core, demonstrating layered separation of concerns with MediatR for command/query handling and CQRS patterns. It includes a sample Angular 8 frontend with TypeScript and a backend API that manages domain entities like Customers, Categories, and Products with full CRUD operations. Clean Architecture monolith with four vertical layers: Src/Application/ contains MediatR handlers, commands, queries, and DTOs; Src/ likely contains Domain and Infrastructure layers (not fully shown); Northwind.WebUI/ holds the Angular SPA with TypeScript components; all organized by domain aggregate (Categories, Customers, Products) with parallel Commands/Queries folders.

.NET developers learning Clean Architecture principles, specifically those building enterprise applications who need to understand how to structure a multi-layer project (Application, Domain, Infrastructure, WebUI) with clear separation between business logic, data access, and presentation layers.

This project is archived and no longer actively maintained—no commits appear to be recent, and it was built to demonstrate Clean Architecture patterns circa 2019. The codebase is stable for learning purposes but not recommended for production use; the author points users to the newer Clean Architecture Solution Template instead.

High risk for production use: the project is explicitly archived with no further updates or support. It uses Angular 8.2.5 and TypeScript 3.4.5 (significantly outdated), Entity Framework Core dependency versions are unspecified, and there is no visible CI/CD pipeline or test coverage metrics in the provided file structure. Single-maintainer risk is eliminated only because the repo is frozen.

Nothing—the repository is archived. No active development, PRs, or milestones are being pursued. It exists as a historical reference snapshot.

Clone the repo with git clone https://github.com/jasontaylordev/NorthwindTraders.git && cd NorthwindTraders. For the backend: open Northwind.sln in Visual Studio and restore NuGet packages. For the frontend: cd into the WebUI folder and run npm install && npm start (based on package.json scripts showing Angular CLI setup).

Daily commands: Backend: Open Visual Studio, build Northwind.sln, run the ASP.NET Core project (likely Src/WebApi or similar). Frontend: cd Src/Northwind.WebUI && npm install && npm start launches the Angular dev server on http://localhost:4200 (typical Angular CLI default). Both must run together for full integration.

• Src/Application/DependencyInjection.cs — Registers all application services and MediatR handlers; essential for understanding the IoC setup and request pipeline configuration.
• Src/Application/Common/Interfaces/INorthwindDbContext.cs — Defines the DbContext contract used throughout the application; fundamental to understanding data access patterns.
• Src/Application/Common/Behaviours/RequestValidationBehavior.cs — Core MediatR pipeline behavior for validation; demonstrates the cross-cutting concern architecture used by all handlers.
• Src/Application/Common/Mappings/MappingProfile.cs — AutoMapper configuration for all DTOs and view models; critical for understanding entity-to-presentation-layer transformations.
• Src/Application/Common/Exceptions/ValidationException.cs — Custom exception handler for validation failures; shows error handling strategy across the entire application.
• Src/Application/Customers/Commands/CreateCustomer/CreateCustomerCommand.cs — Exemplary CQRS command implementation; demonstrates the pattern used throughout for all create/update/delete operations.
• Src/Application/Products/Queries/GetProductsList/GetProductsListQueryHandler.cs — Exemplary query handler implementation; shows how data flows from DbContext through mapping to view models.

Add a new entity with CRUD operations

1. Create command folder: Src/Application/Orders/Commands/CreateOrder/ (Src/Application/Orders/Commands/CreateOrder/CreateOrderCommand.cs)
2. Define CreateOrderCommand extending IRequest<OrderDto> with validation (Src/Application/Orders/Commands/CreateOrder/CreateOrderCommand.cs)
3. Implement CreateOrderCommandHandler : IRequestHandler<CreateOrderCommand, OrderDto> (Src/Application/Orders/Commands/CreateOrder/CreateOrderCommandHandler.cs)
4. Create corresponding query handler in Src/Application/Orders/Queries/GetOrdersList/GetOrdersListQueryHandler.cs (Src/Application/Orders/Queries/GetOrdersList/GetOrdersListQueryHandler.cs)
5. Add mapping profile entry in MappingProfile.cs for the new entity DTOs (Src/Application/Common/Mappings/MappingProfile.cs)
6. Register new handlers in DependencyInjection.cs via services.AddMediatR() (Src/Application/DependencyInjection.cs)

Add validation to an existing command

1. Create validator file: Src/Application/Customers/Commands/CreateCustomer/CreateCustomerCommandValidator.cs (Src/Application/Customers/Commands/CreateCustomer/CreateCustomerCommandValidator.cs)
2. Inherit from AbstractValidator<CreateCustomerCommand> and add RuleFor() chains (Src/Application/Customers/Commands/CreateCustomer/CreateCustomerCommandValidator.cs)
3. RequestValidationBehavior will automatically invoke validators during command processing (Src/Application/Common/Behaviours/RequestValidationBehavior.cs)

Add a new query handler with filtering/sorting

1. Create query class in Src/Application/Products/Queries/GetProductsList/GetProductsListQuery.cs with filter properties (Src/Application/Products/Queries/GetProductsList/GetProductsListQuery.cs)
2. Implement handler injecting INorthwindDbContext to query and map entities (Src/Application/Products/Queries/GetProductsList/GetProductsListQueryHandler.cs)
3. Apply LINQ filters based on query properties; use .ProjectTo<ProductDto>() for AutoMapper projection (Src/Application/Products/Queries/GetProductsList/GetProductsListQueryHandler.cs)
4. Return view model (ProductsListVm) with mapped list of DTOs (Src/Application/Products/Queries/GetProductsList/ProductsListVm.cs)

• ASP.NET Core — Enterprise-grade web framework for building scalable REST APIs with dependency injection and middleware support
• Entity Framework Core — ORM for data access with LINQ query support, automatic change tracking, and database migrations
• MediatR — Implements CQRS pattern to decouple commands/queries from handlers, enabling cross-cutting concerns via pipeline behaviors
• AutoMapper — Reduces boilerplate for entity-to-DTO mapping with convention-based configuration
• FluentValidation — Fluent API for building strongly-typed validation rules with reusable validator classes
• Angular 8 — Frontend framework for building responsive single-page application with TypeScript and reactive forms

• Archived project - not actively maintained

  • Why: Original developer created a newer Clean Architecture template; this version demonstrates basic principles only
  • Consequence: Users must fork and update dependencies (Angular 8 is old, .NET Core version outdated); no security patches

• CQRS pattern with separate command/query handlers

  • Why: Enables independent scaling and optimization of reads vs. writes; clear separation of concerns
  • Consequence: More boilerplate code per entity; small performance overhead from dispatching through MediatR pipeline

• All validation in validators, not in command handlers

  • Why: Centralized validation via RequestValidationBehavior pipeline behavior applied to all requests
  • Consequence: Validation errors thrown as exceptions rather than inline checks; slightly more abstraction

• AutoMapper for all DTO mappings

  • Why: Eliminates manual mapping code and enables projection directly from LINQ queries
  • Consequence: Configuration scattered across MappingProfile.cs; implicit mappings can hide bugs

No database connection string visible in the provided files—you must configure Entity Framework Core's database provider (likely SQL Server) in appsettings.json or via dependency injection setup in an unreferenced Startup/Program.cs file. The Angular build script build:ssr references ASP.NET Core prerendering, implying server-side rendering is configured but may require additional Node.js/TypeScript compilation setup. The repository is archived and frozen—attempting to upgrade dependencies may break the demonstration value. FluentValidation validators must be registered in the DI container (not shown in file list), so check the Startup or Program file for services.AddValidatorsFromAssembly().

• Clean Architecture — This entire project is structured around Clean Architecture principles—understanding the four-layer model (Presentation, Application, Domain, Infrastructure) with dependency arrows pointing inward is fundamental to navigating and modifying this codebase
• CQRS (Command Query Responsibility Segregation) — The project's use of MediatR with separate Command and Query classes (e.g., CreateCustomerCommand vs. GetCategoriesListQuery) implements CQRS—understanding why reads and writes are separated is crucial for modifying data access patterns
• MediatR Pipeline Behaviors — The project decorates all requests with cross-cutting behaviors like RequestValidationBehavior, RequestLogger, and RequestPerformanceBehaviour—this pattern allows adding logging, validation, and monitoring without modifying individual handlers
• AutoMapper IMapFrom<T> Convention — DTOs in Src/Application/*/Queries/ implement IMapFrom<T> which the MappingProfile auto-discovers—this convention avoids boilerplate map configuration and is key to understanding how entities transform into view models
• Dependency Injection (DI) Container — Handlers, validators, and services are injected via a DI container—all request handlers accept dependencies in their constructors, making the container configuration (likely in a Startup.cs file not shown) critical for connecting everything
• Entity Framework Core DbContext Abstraction — All data access goes through INorthwindDbContext (an interface over EF Core's DbContext)—this abstraction allows swapping implementations and testing without touching the database
• FluentValidation with ASP.NET Core Pipeline — Request validators (e.g., CreateCustomerCommandValidator) inherit from AbstractValidator<T> and are executed automatically by RequestValidationBehavior—this decouples validation logic from handlers and makes it reusable

• jasontaylordev/CleanArchitecture — The officially maintained successor to this archived repo—same author, demonstrates updated Clean Architecture patterns with modern .NET 6+ and Angular versions
• ardalis/CleanArchitecture — Alternative Clean Architecture template by Steve Smith (Ardalis)—similar layering philosophy but different implementation and tooling choices
• microsoft/eShopOnWeb — Microsoft's own Clean Architecture reference implementation using ASP.NET Core and Entity Framework—production-quality patterns for building maintainable e-commerce systems
• angular/angular — The Angular framework repository—essential context since this project uses Angular 8; reviewing the framework's architecture helps understand the WebUI layer
• jbogard/MediatR — Jimmy Bogard's MediatR library used throughout this project—the canonical source for understanding how MediatR pipelines and handlers work

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add unit tests for Application layer command validators

The repo contains multiple command validators (e.g., CreateCustomerCommandValidator.cs, UpdateCustomerCommandValidator.cs, DeleteCustomerCommandValidator.cs, GetCustomerDetailQueryValidator.cs) but there's no evidence of unit test coverage for these validators. This is critical since validators enforce business rules at the application boundary. A new contributor could add xUnit tests in a Tests/Application folder to validate both passing and failing cases for each validator, improving code reliability and serving as documentation.

• [ ] Create Tests/Application/Customers/Commands/CreateCustomer/CreateCustomerCommandValidatorTests.cs
• [ ] Create Tests/Application/Customers/Commands/UpdateCustomer/UpdateCustomerCommandValidatorTests.cs
• [ ] Create Tests/Application/Customers/Commands/DeleteCustomer/DeleteCustomerCommandValidatorTests.cs
• [ ] Create Tests/Application/Customers/Queries/GetCustomerDetail/GetCustomerDetailQueryValidatorTests.cs
• [ ] Add xUnit test cases for valid/invalid inputs for each validator
• [ ] Update README with instructions on running tests

Add integration tests for MediatR pipeline behaviors

The repo implements custom pipeline behaviors in Src/Application/Common/Behaviours/ (RequestLogger.cs, RequestPerformanceBehaviour.cs, RequestValidationBehavior.cs) but there are no visible tests validating that these behaviors execute correctly within the MediatR pipeline. A contributor could add integration tests demonstrating that logging, performance monitoring, and validation are triggered properly for actual command/query execution.

• [ ] Create Tests/Application/Common/Behaviours/RequestLoggerTests.cs to verify logging output
• [ ] Create Tests/Application/Common/Behaviours/RequestPerformanceBehaviourTests.cs to verify timing is recorded
• [ ] Create Tests/Application/Common/Behaviours/RequestValidationBehaviorTests.cs to verify invalid requests are caught
• [ ] Use a test MediatR instance with in-memory handlers
• [ ] Document behavior testing approach in docs or inline comments

Add missing query handlers for Employees and Categories modules

The file structure shows Src/Application/Employees/Queries/GetEmployeesList/ and Src/Application/Employees/Queries/GetEmployeeDetail/ exist, but there are no visible handler files (GetEmployeesListQueryHandler.cs, GetEmployeeDetailQueryHandler.cs). Similarly, Categories has a GetCategoriesListQueryHandler but may lack handlers for other expected operations. A contributor could implement these missing handlers following the established pattern in Customers module (e.g., GetCustomersListQueryHandler.cs).

• [ ] Create Src/Application/Employees/Queries/GetEmployeesList/GetEmployeesListQueryHandler.cs following GetCustomersListQueryHandler.cs pattern
• [ ] Create Src/Application/Employees/Queries/GetEmployeeDetail/GetEmployeeDetailQueryHandler.cs
• [ ] Create corresponding DTO/ViewModel classes (EmployeeListVm.cs, EmployeeLookupDto.cs if missing)
• [ ] Create Src/Application/Employees/Queries/GetEmployeesList/GetEmployeesListQuery.cs if missing
• [ ] Register new handlers in DependencyInjection.cs
• [ ] Add unit tests for new handlers following established pattern

• Add unit tests for the MediatR handlers in Src/Application/Customers/Commands/ and Src/Application/Categories/Queries/—currently no test project is visible in the file list, creating a good opportunity to demonstrate Clean Architecture testability by writing isolated tests for command/query handlers.
• Document the Project structure with an architecture diagram in Docs/ showing how the four layers (Application, Domain, Infrastructure, WebUI) interact and where MediatR fits—the README is generic and archived, so a visual guide referencing actual file paths would help learners.
• Implement an INotificationService consumer in the WebUI Angular layer (reference exists in Src/Application/Common/Interfaces/INotificationService.cs but no frontend integration is evident) to show how the backend notifies the Angular SPA of domain events like CustomerCreated.cs.

• High · Archived Project - No Active Maintenance — Repository-wide (README.md, project status). The repository is archived and no longer actively maintained or supported. This means security vulnerabilities will not be patched, and the codebase may contain unaddressed security issues. Users are directed to use the updated Clean Architecture Solution Template instead. Fix: Migrate to the actively maintained Clean Architecture Solution Template (https://github.com/jasontaylordev/CleanArchitecture). Do not use this archived version in production environments.
• High · Outdated Angular Dependencies with Known Vulnerabilities — package.json - dependencies section. The project uses Angular 8.2.5 (released in 2019) which is significantly outdated. Multiple known CVEs exist for this version and its dependencies including @angular/core, @angular/common, and @angular/platform-browser. The TypeScript version (3.4.5) and associated tooling are also outdated. Fix: Update to the latest stable versions of Angular (currently v17+) and TypeScript (5.x+). Run 'npm audit' and address all reported vulnerabilities. Consider using 'npm audit fix' to automatically patch vulnerabilities.
• High · Vulnerable oidc-client Library Version — package.json - oidc-client dependency. The project uses oidc-client version ^1.9.1, which is an outdated version with known security vulnerabilities. This library handles authentication tokens and sensitive user information. Fix: Update to oidc-client-ts (the maintained fork) or the latest oidc-client version. Verify OIDC implementation includes secure token storage, PKCE, and proper CORS configuration.
• High · Outdated core-js Dependency — package.json - core-js dependency. core-js version ^2.6.5 is outdated and no longer maintained. Modern toolchains should not require explicit core-js imports for most use cases. Fix: Remove or update core-js to version 3.x if needed. Most modern Angular applications handle polyfills automatically. Verify polyfill strategy aligns with your target browser support.
• Medium · Deprecated ngx-bootstrap Version — package.json - ngx-bootstrap dependency. ngx-bootstrap version ^5.1.1 is outdated (released in 2019). This library may contain unpatched security vulnerabilities in its dependencies. Fix: Update to the latest stable version of ngx-bootstrap (currently 12.x+). Review changelog for breaking changes and test thoroughly.
• Medium · Outdated Development Dependencies — package.json - devDependencies section. Multiple dev dependencies are significantly outdated: TypeScript 3.4.5 (2019), @angular/cli 8.3.3 (2019), Karma 4.0.0, and testing frameworks. These may contain known vulnerabilities and lack security patches. Fix: Update all dev dependencies to current versions: TypeScript to 5.x+, @angular/cli to latest, Karma to 6.x+, Jasmine to latest 4.x or 5.x. Run 'npm audit' after updates.
• Medium · Optional Dependencies with Known Issues — package.json - optionalDependencies section. Optional dependencies include node-sass (superseded by sass), protractor (deprecated testing tool), and tslint (deprecated in favor of ESLint). These may have unpatched vulnerabilities. Fix: Remove node-sass and use sass instead. Remove protractor and use Cypress or Playwright for e2e testing. Replace tslint with ESLint using @angular-eslint packages.
• Medium · No Evidence of Security Headers or HTTPS Enforcement — Src/Application/DependencyInjection.cs and Startup configuration (not shown). No visible security header configuration in startup files, middleware, or deployment configuration. The codebase structure does not show evidence of security headers (CSP, HSTS, X-Frame-Options, etc.) or HTTPS enforcement. Fix: Implement security headers middleware in the ASP.NET Core application. Add HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options headers. Enforce HTTPS redirection

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.