wip league admin tools

docs/architecture/USECASES.md

@@ -120,6 +120,20 @@ Rules:
 
 3. API Layer
 
+API Services / Controllers (Thin Orchestration)
+
+The API layer is a transport boundary. It MUST delegate business logic to `./core`:
+
+	•	orchestrate auth + authorization checks (actor/session/roles)
+	•	collect/validate transport input (DTOs at the boundary)
+	•	execute a Core use case (entities/value objects live here)
+	•	map Result → DTO / ViewModel via a Presenter (presenter owns mapping)
+
+Rules:
+	•	Controllers stay thin: no business rules, no domain validation, no decision-making
+	•	API services orchestrate: auth + use case execution + presenter mapping
+	•	Domain objects never cross the API boundary un-mapped
+
 Presenter
 
 @Injectable()
@@ -287,6 +301,12 @@ Rules:
 
 ⸻
 
+Do / Don’t (Boundary Examples)
+
+	✅ DO: Keep pages/components consuming ViewModels returned by website services (DTOs stop at the service boundary), e.g. [LeagueAdminSchedulePage()](apps/website/app/leagues/[id]/schedule/admin/page.tsx:12).
+	✅ DO: Keep controllers/services thin and delegating, e.g. [LeagueController.createLeagueSeasonScheduleRace()](apps/api/src/domain/league/LeagueController.ts:291).
+	❌ DON’T: Put business rules in the API layer; rules belong in `./core` use cases/entities/value objects, e.g. [CreateLeagueSeasonScheduleRaceUseCase.execute()](core/racing/application/use-cases/CreateLeagueSeasonScheduleRaceUseCase.ts:38).
+
 6. Optional Extensions
 
 Custom Output Ports