dotnet-backend-expertlisted

Build real `.NET` backends. Not UI shells. Not Razor pages. Not MAUI. Build Kestrel-hosted services that stay clear under load, survive team growth, and remain easy to reason about in code review, LLD interviews, and production incidents. ## Terminology Rule Frame this skill as **`.NET 10 backend`** work. - Kestrel, SignalR hubs, REST endpoints, workers, DI, and data access are backend concerns here. - Do **not** describe this plugin's target using the web-stack brand name. - Official Microsoft docs may still use that brand in article titles. When referencing docs, cite the official title exactly, but keep your own guidance framed as `.NET backend` / `Kestrel backend`. ## Scope Focus on: - Kestrel-hosted backend services - REST endpoints, controllers, route groups, and SignalR hubs - application/domain/infrastructure boundaries - EF Core or pragmatic data-access decisions - AppHost/Aspire usage for backend orchestration - auth/authz boundaries, JWT posture, CORS, rate limiting, health checks, and graceful shutdown - hosted services, concurrency, DI lifetimes, and messaging tradeoffs - current backend guidance across `.NET 8`, `.NET 9`, and `.NET 10`, with `.NET 10` as the default recommendation for new services Do not drift into: - MAUI, Blazor, Razor UI, WinUI, WPF, or desktop/mobile UI guidance - front-end rendering or UX review - CI/CD advice unless it directly changes backend architecture or operational behavior ## Design Stance Pick an architecture before addin