Consolidate shallow pass-through use cases into workflow-level domain modules

[jjoonleo]

Problem

The domain use-case layer mixes deep workflow modules with many shallow pass-through modules. The shallow modules expose one interface per repository method, but their implementation often just forwards arguments. That adds constructor dependencies, test doubles, and files without much leverage or locality.

Evidence

• ReconcileAlarmsUseCase is a deep counterexample: it owns in-flight dedupe, schedule/alarm windows, capability checks, settings handling, desired/stale record reconciliation, and permission checks behind one workflow interface.
• wc -l lib/domain/use-cases/*.dart shows many use-case files are very small.
• Shallow examples include ClearEarlyStartSessionUseCase, StartScheduleUseCase, UpdateSpareTimeUseCase, and GetPreparationTemplatesUseCase, which mostly rename repository calls.
• Caller/test burden is visible in ScheduleBloc, which injects many single-operation use cases, and in tests that define matching spy/stub classes for them.

Proposed direction

Audit lib/domain/use-cases/ with a deletion test: keep modules that hide workflow policy, orchestration, validation, error mapping, analytics, reconciliation, or date/range semantics; consolidate modules that only forward to a repository.

Candidate consolidation areas:

• Schedule preparation session workflow: start/finish, timed preparation snapshot, early-start mark/get/clear, alarm cleanup.
• Schedule calendar workflow: date/week/month loading plus stream subscription semantics.
• Preparation/template workflows: default preparation, spare time, template CRUD, and custom preparation operations.

Presentation should continue depending on domain use cases, not remote data sources or repository implementations.

Acceptance criteria

• Every current use case is classified as keep, deepen, consolidate, or delete in the PR description or a short repo-local plan.
• At least one schedule/preparation family is consolidated into a deeper workflow-level use case, reducing constructor dependencies in the affected Bloc/Cubit.
• Delegation-only tests are replaced or narrowed so tests assert workflow behavior, not just repository method forwarding.
• Injectable/generated files are updated if DI wiring changes.
• flutter analyze and targeted tests for changed domain/presentation paths pass.

Source: Codex codebase audit on 2026-06-28.