scaffold-controller

Provide the service name and entity name as arguments, and the scaffold generates a controller where each endpoint calls _mediator.Send with the corresponding command or query. The controller stays thin with no business logic inside.

The generated controller includes GET list, GET by id, POST create, PUT update, DELETE soft-delete, and PATCH restore endpoints. Custom actions can be added as PATCH routes under /{id}/action.

The scaffold applies [Authorize] for authenticated users on create and update, and [Authorize(Policy = "AdminOnly")] for delete and restore. GET list and detail endpoints remain public by default, and ManagerOnly policy is available for adjustment.

Routes are lowercase, plural, and kebab-case, such as /api/battery-logs. POST and PUT bind from the request body with [FromBody], while GET endpoints bind parameters with [FromQuery].

Avoid scaffolding when the endpoint does not map to standard CRUD operations, such as webhook receivers, file streaming, or aggregate reporting endpoints. Those cases need hand-written controllers with custom logic beyond MediatR command dispatch.