Salon/docs/execplans/booking-notifications.md

Booking Lifecycle Notifications

This ExecPlan follows docs/PLANS.md.

Purpose / Big Picture

Notify customer and staff on booking created/confirmed/cancelled with auditable notification rows.

Progress

• (2026-02-28 17:05Z) Plan + scope finalized.
• (2026-02-28 17:40Z) Notification app + providers + booking wiring implemented.
• (2026-02-28 18:05Z) Tests added for create/status-change/no-duplicate behavior.
• (2026-02-28 18:10Z) Risks/docs updated.

Surprises & Discoveries

• Observation: status field had been read-only for update flow. Evidence: PATCH /api/bookings/<id> validation failure before serializer update.

Decision Log

• Decision: persist notification records for every lifecycle send attempt. Rationale: auditability + support traceability. Date/Author: 2026-02-28/Codex
• Decision: reuse OTP provider abstraction for notification channels. Rationale: avoid duplicated provider integration. Date/Author: 2026-02-28/Codex

Outcomes & Retrospective

Completed. Booking lifecycle notifications are live with idempotent records and test coverage.

Context and Orientation

• Notification domain: backend/apps/notifications/
• Booking integration points: backend/apps/bookings/views.py

Plan of Work

Completed; future work is provider hardening/monitoring only.

Validation and Acceptance

From backend/:

• python3 -m pytest backend/apps/notifications/tests Acceptance:
• Create/confirm/cancel each emit customer+staff notification rows once per event/channel.

Idempotence and Recovery

Uniqueness constraints prevent duplicate event/channel sends per recipient/booking; retries update existing rows safely.