dotnet-code-review

name	dotnet-code-review
description	Review .NET code for quality, security, performance, and architectural compliance following DDD and Clean Architecture standards. Use when user says "review code", "code review", "PR review", "check quality", "review my changes", or asks for feedback on code. Also use proactively after significant code changes. For this repository, API/Minimal API code in src/Api must not be reviewed against MVC/Razor expectations; do not suggest dotnet-mvc patterns unless the work is explicitly MVC.
metadata	{"author":"Claude-DotNet-Ultimate","version":"1.1.0","category":"code-quality"}

.NET Code Review Standards

Project type (API vs MVC)

• This monorepo is API-first (src/Api/, Minimal APIs). Reviews of src/Api/ and Application/Infrastructure for API flows should not flag “missing Controllers/Views” or recommend dotnet-mvc unless the user is adding a separate MVC app.
• If the project under review is API-only or the user said they use REST/Minimal API, do not use or recommend dotnet-mvc in findings.

Review Process

1. Run git diff to see changes
2. Identify modified files and their layer (Domain/Application/Infrastructure/Api)
3. Apply layer-specific checks
4. Report findings by priority

Priority Levels

• CRITICAL — Must fix: Security vulnerabilities, data loss risks, broken functionality
• WARNING — Should fix: Performance issues, architectural violations, code smells
• SUGGESTION — Consider improving: Style, naming, documentation

Layer-Specific Checks

Domain Layer (src/Core/)

• Entities have private setters and factory methods
• No infrastructure references (EF Core, MassTransit, etc.)
• Value objects are immutable
• Domain events raised on state changes
• Business rules enforced inside entity methods
• Strongly-typed IDs used (not raw Guid)
• No anemic domain models

Application Layer (src/Application/)

• Commands return Result<T> (no exceptions for flow control)
• All commands have FluentValidation validators
• Queries use cache before database
• Primary constructors for DI
• DTOs are sealed record types
• No direct infrastructure dependencies (only interfaces)

Infrastructure Layer (src/Infrastructure/)

• snake_case for table/column names
• Value objects mapped as owned entities
• Strongly-typed ID conversions configured
• AsNoTracking() for read-only queries
• Parameterized queries (no raw SQL injection)
• Retry policies on external calls
• DomainEvents property ignored in configurations

API Layer (src/Api/)

• Error responses use ProblemDetails
• ErrorType mapped to correct HTTP status
• CancellationToken passed to all async methods
• WithOpenApi() for documentation
• Route constraints on parameters

NEVER-DO Violations (Critical)

These are always CRITICAL findings:

Violation	Check For
throw ex;	Must use throw; or throw new CustomException()
.Result or .Wait()	Must await async methods
async void	Must be async Task or async ValueTask
DateTime.Now	Must use DateTime.UtcNow or IClock
ArrayList / Hashtable	Must use generic collections
Catching Exception	Must catch specific types or re-throw
String interpolation in logs	Must use message templates
Task.Run in async code	Avoid unless bridging sync-to-async

Performance Checks

• No N+1 queries (check Include/eager loading)
• No unnecessary allocations in hot paths
• Span for parsing operations
• IAsyncEnumerable for streaming large datasets
• AsSplitQuery() when multiple Includes

Security Checks

• No secrets in code or config files
• Input validation on all endpoints
• Parameterized database queries
• CORS properly configured
• No sensitive data in logs

Output Format

## Code Review: [PR/Change Description]

### CRITICAL
- **[File:Line]**: Description of issue
  - **Fix**: How to resolve

### WARNING
- **[File:Line]**: Description of issue
  - **Fix**: How to resolve

### SUGGESTION
- **[File:Line]**: Description of improvement
  - **Suggestion**: What to change

### Summary
- X critical, Y warnings, Z suggestions
- Overall assessment: [APPROVE / REQUEST CHANGES / NEEDS DISCUSSION]