# 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
- [x] (2026-02-28 17:05Z) Plan + scope finalized.
- [x] (2026-02-28 17:40Z) Notification app + providers + booking wiring implemented.
- [x] (2026-02-28 18:05Z) Tests added for create/status-change/no-duplicate behavior.
- [x] (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.