chore: condense all docs and markdown files

docs/runbooks/booking_failures.md

@@ -1,40 +1,28 @@
 # Runbook: Booking Failures
 
-## Summary
-
-Guide for diagnosing booking creation or status update failures (availability, overlap prevention, or validation errors).
-
 ## Symptoms
-
-- `POST /api/bookings/` returns HTTP 400 or 500.
-- `PATCH /api/bookings/<id>/` fails when confirming or cancelling.
-- Users report bookings not appearing or incorrect status.
+- `POST /api/bookings/` fails (400/500).
+- Booking status update fails.
+- Booking missing/incorrect in listing.
 
 ## Impact
-
-- Customers cannot place bookings.
-- Staff schedules become inconsistent.
-- Notification and payment flows may not trigger.
+Customers cannot book; staff schedule integrity degrades; dependent flows break.
 
 ## Quick Checks
+- Validate payload: `service`, `staff`, `start_time`, `end_time`.
+- Check logs for validation/integrity errors.
+- Confirm staff availability + overlap expectations.
+- If notifications expected, confirm provider config + notification rows.
 
-- Confirm the request payload includes a valid `service`, `staff`, and scheduled time.
-- Check server logs for booking validation errors or integrity exceptions.
-- Verify that staff availability and overlap prevention rules are behaving as expected.
+## Mitigation
+1. Reproduce with known test data.
+2. Inspect booking validation service and serializer permissions.
+3. Confirm timezone assumptions for failing case.
+4. If regression after deploy, roll back booking-related change.
 
-## Mitigation Steps
+## Escalation
+Share booking id, user id, timestamps, and failing payload/response with engineering.
 
-- Reproduce with a known test user and staff member to isolate data issues.
-- If overlap rules are too strict, review booking validation logic and confirm time zone assumptions.
-- If status updates are blocked, verify role checks and serializer permissions in `backend/apps/bookings/`.
-- If notifications are expected but missing, confirm `NOTIFICATION_PROVIDER` configuration and notification records.
-
-## Rollback / Escalation
-
-- Roll back recent booking-related changes if failures started after a deployment.
-- Escalate to engineering with the booking ID, user ID, and timestamps.
-
-## Notes
-
-- Booking validation and status transitions live in `backend/apps/bookings/`.
-- Notifications for booking lifecycle are handled in `backend/apps/notifications/`.
+## References
+- Booking logic: `backend/apps/bookings/`
+- Notification logic: `backend/apps/notifications/`