code-review-and-quality

Review .NET pull requests across five axes: correctness, readability, architecture, security, and performance. Start by understanding the change intent, review tests first, then walk the implementation, and label every finding with a severity prefix like Critical, Nit, or Optional.

Check async correctness (no sync-over-async, CancellationToken threading), edge cases like null and default(T), EF Core N+1 patterns, FromSqlRaw usage, DI registration lifetimes, secrets handling, and whether dotnet test and dotnet build -warnaserror pass.

Yes, the five axes apply universally, but individual checks are host-specific. Server-side items like antiforgery tokens do not apply to Avalonia clients, while client-side items like dispatcher marshalling do not apply to ASP.NET Core APIs.

Target around 100 lines changed for a change reviewable in one sitting; 300 lines is acceptable for a single logical change. Around 1000 lines is too large and should be split by stacking, by project, or into vertical feature slices.

Library code consumed from hosts with a SynchronizationContext (WPF, WinForms, MAUI, Avalonia UI thread) should use ConfigureAwait(false) on public awaits. It is unnecessary for code running only under ASP.NET Core, which has no SynchronizationContext since .NET Core 2.1.