Centralize schedule mutation alarm side effects

[jjoonleo]

Problem

Schedule persistence and alarm maintenance are coupled across the create, update, delete, and finish schedule use cases. Each mutation owns a slightly different mix of repository persistence, targeted alarm cancellation, and best-effort reconciliation, which makes the alarm contract implicit and easy to miss when adding or changing schedule mutations.

Evidence

• lib/domain/use-cases/create_schedule_with_place_use_case.dart creates the schedule, then fires unawaited(_reconcileAlarmsUseCase()).
• lib/domain/use-cases/update_schedule_use_case.dart repeats the same persistence plus unawaited reconciliation pattern.
• lib/domain/use-cases/delete_schedule_use_case.dart deletes, cancels the schedule alarm, then fires reconciliation.
• lib/domain/use-cases/finish_schedule_use_case.dart starts/finishes, cancels the schedule alarm, then fires reconciliation.
• test/domain/use-cases/schedule_mutation_use_cases_test.dart mirrors this scattering with separate alarm side-effect assertions for create/update, delete, and finish.

Proposed direction

Introduce a shared domain-level schedule mutation alarm side-effect coordinator. The four mutation use cases should keep owning schedule persistence, then delegate an explicit operation type such as created, updated, deleted, or finished to the coordinator.

That coordinator should own whether to cancel the mutated schedule alarm, whether to reconcile, and whether the operation is awaited or best-effort.

Acceptance criteria

• Create/update/delete/finish no longer inject ReconcileAlarmsUseCase directly.
• Delete/finish still cancel the mutated schedule's native/fallback alarm record before global reconciliation.
• Create/update still trigger reconciliation after successful persistence and do not trigger it on repository failure.
• Tests cover the shared coordinator and each mutation operation type.
• Presentation schedule flows do not need to know whether a mutation cancels or reconciles alarms.

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