code-review-checklist

name	code-review-checklist
description	Structured checklist for reviewing pull requests in the Menu repository — layer separation, Vogen coverage, Mapperly attributes, async conventions, and StyleCop compliance.
user-invokable	true
context	inline

Code Review Checklist

Purpose

Use this skill when reviewing a pull request against the Menu repository. Work through each section in order and flag any item that fails.

1. Layer separation

The three model layers must never be mixed:

• EF entities (backend/MenuDB/Data/) are not referenced directly from MenuApi controllers or services — only from repository implementations.
• DB models (backend/MenuApi/DBModel/) are not returned from API endpoints — only from repository methods.
• ViewModels (backend/MenuApi/ViewModel/) are not passed into repository methods — only into and out of service methods.
• No raw EF DbContext usage outside of repository implementations.

2. Vogen value objects

• New domain identifiers and constrained values use Vogen types — not raw int, string, or Guid.
• Repository code uses .Value to unwrap and TypeName.From(x) to wrap.
• New value objects are placed in backend/MenuApi/ValueObjects/.

3. Mapperly mappings

• Any new or renamed property on a ViewModel or DB model has a corresponding [MapProperty] attribute update in backend/MenuApi/MappingProfiles/ViewModelMapper.cs.
• The solution builds without warnings (build with --configuration Release to confirm, since TreatWarningsAsErrors is enabled).

4. Async conventions

• Every await call in service and repository implementations has ConfigureAwait(false).
• No blocking calls (.Result, .Wait()) on Task in service or repository code.

5. Dependency injection

• New repositories and services are registered in backend/MenuApi/Program.cs.
• Interfaces are used for DI registrations (e.g. IRecipeService, not RecipeService).

6. API endpoints

• Each new endpoint is documented with .Produces<T>(statusCode), .ProducesProblem(statusCode), and/or .ProducesValidationProblem() — do not use .WithName(...) or .WithOpenApi().
• The generated frontend types (src/generated/open-api/menu-api.ts) are updated in the same commit as the endpoint change (run pnpm generate-openapi in ui/menu-website/). Note: open-api/menu-api.json is gitignored and should not be committed.

7. StyleCop and code style

• No StyleCop suppressions added without a justifying comment.
• using directives are ordered per StyleCop rules.
• public partial class Program remains in Program.cs for integration test WebApplicationFactory compatibility.

8. Tests

• New service or repository logic has corresponding unit tests in MenuApi.Tests.
• Unit tests use [CustomAutoData] (not bare [AutoData]) to handle Vogen specimen construction.
• Assertions use AwesomeAssertions (.Should()) — not xUnit raw assertions or FluentAssertions.
• New integration tests carry [Collection("API Host Collection")].
• Integration test string parameters use [StringLength(N, MinimumLength = 1)] to avoid varchar overflow and [NoAutoProperties] to prevent constraint violations from auto-populated collections.

9. Frontend (if applicable)

• No hand-written types in src/generated/ — types are always generated by pnpm generate-openapi.
• New components have a co-located Storybook story (*.stories.ts).
• Pages and components use the service layer — never the API layer (recipe-api.ts) directly.
• import type is used for type-only imports.