code-review-and-quality

Code Review and Quality

Overview

Multi-dimensional code review with quality gates. Every change gets reviewed before merge — no exceptions. Review covers five axes: correctness, readability, architecture, security, and performance.

The approval standard: Approve a change when it definitely improves overall code health, even if it isn't perfect. Perfect code doesn't exist — the goal is continuous improvement. Don't block a change because it isn't exactly how you would have written it. If it improves the codebase and follows the project's conventions, approve it.

When to Use

• Before merging any PR or change
• After completing a feature implementation
• When another agent or model produced code you need to evaluate
• When refactoring existing code
• After any bug fix (review both the fix and the regression test)

The Five-Axis Review

Host-model lens. The five axes apply universally. Individual bullets sometimes anchor on a specific host model — server-side (ASP.NET Core) items like N+1 EF Core patterns, FromSqlRaw, antiforgery tokens, and [Authorize] policy checks won't apply to a pure Avalonia/MAUI client; client-side (Avalonia / MAUI / Blazor WebAssembly) items like dispatcher marshalling and localStorage discipline won't apply to an ASP.NET Core API. Where a bullet is host-specific, the host is named inline.

Every review evaluates code across these dimensions:

1. Correctness

Does the code do what it claims to do?

• Does it match the spec or task requirements?
• Are edge cases handled (null, empty, boundary values, default(T))?
• Are error paths handled (not just the happy path)?
• Are async methods correctly awaited? No sync-over-async (.Result / .Wait()) on I/O paths?
• Does it pass all tests (dotnet test)? Are the tests actually testing the right things?
• Are there off-by-one errors, race conditions, or state inconsistencies?
• Is CancellationToken threaded through I/O methods?
• For library code (NuGet packages, class libraries that may be consumed from non-ASP.NET-Core hosts — WPF, WinForms, MAUI, Avalonia UI thread), do public await expressions use .ConfigureAwait(false) to avoid capturing the caller's SynchronizationContext? (Not needed for code that only runs under ASP.NET Core — it has no SynchronizationContext since .NET Core 2.1.)