incremental-implementation

Break the feature into thin vertical slices where each slice delivers working end-to-end functionality, such as one EF Core entity plus migration plus endpoint plus view. After each slice, run dotnet test and dotnet build -warnaserror, then commit before starting the next slice.

Vertical slicing builds one complete path through the stack per increment, for example create-task with entity, migration, endpoint, and view, rather than building all backend layers first. Each slice leaves the system in a working, testable state.

Use feature flags when a feature is incomplete but you need to merge increments to the main branch. Configure them with IOptions<FeatureOptions> bound to appsettings.json, which works identically in ASP.NET Core, Avalonia, and MAUI hosts.

Yes, library slices consumed from WPF, WinForms, MAUI, or Avalonia UI-thread callers should add ConfigureAwait(false) on every public await, because those hosts capture SynchronizationContext and resuming on it can deadlock. ASP.NET Core has no sync context since .NET Core 2.1, so it is a no-op there.

Skip it for single-file, single-method changes where the scope is already minimal. The discipline targets multi-file features, refactors, and any change where you would otherwise write more than roughly 100 lines before testing.

Hand-editing a migration after it has been applied to a shared environment breaks rollback, because the generated Down method no longer matches the actual schema state. Always create a new migration with dotnet ef migrations add instead of modifying an applied one.