Draft — согласовано, до разбивки на задачи

Booking lifecycle: модель, права, state machine

Заменяет модель BOOKING/BID — переопределяет user_id/вводит client_id, добавляет WAIT_PAYMENT/REJECTED, историю переходов и разделение точек входа создания. Код под это ещё не написан — только дизайн-документы.

Принципы

1. Три источника истины: сам пользователь (ЛК), гость через confirm, OTA (синхронизация с внешними площадками — Avito, Суточно.ру и т.д., будущая итерация, сейчас только точка расширения). Онлайн-оплата аналогично — переход WAIT_PAYMENT → BOOKED закладывается как системное действие по колбэку, сам шлюз не подключается.
2. Клиент — только чтение, кроме самоотмены своей заявки, пока статус BID или WAIT_PAYMENT.
3. Платформа не несёт ответственности за действия владельца после оплаты — эскроу/ автовозврата/разбора споров нет, гарантия — только полный аудиторский след.
4. Права — через владение (housing.user_id), не через роли.

Модель данных

BookingStatusType — новый набор

Старое значение BOOKING переименовывается в BOOKED везде по коду. Default в БД остаётся BID.

BookingSourceType — «кто создал», не «какая площадка»

Старый вариант (MANUAL/AVITO/SUTOCHNO в одном enum) смешивал два разных вопроса — кто инициировал заявку и через какую конкретно внешнюю площадку она пришла. Разделено на два поля.

OtaPlatformType — какая именно площадка

Новый catalog-файл shared/catalogs/booking/ota-platform.ts, тот же паттерн createType():

Заполняется в Booking.ota_platform только когда source === OTA. Расширяется добавлением строки в этот список — не трогает BookingSourceType. Каждая площадка в будущем получит свой класс-адаптер синхронизации, подключаемый по значению ota_platform (например реестр Record<OtaPlatformType, OtaAdapter>) — сам интерфейс адаптера не проектируется сейчас.

BookingStatusHistory — новая сущность

booking_status_history
  id
  booking_id           FK -> booking, CASCADE
  from_status           nullable enum   (null для создания)
  to_status              enum
  changed_by_user_id   nullable int    (null = системное действие)
  reason                 nullable text
  created_at             timestamp

Пишется при каждом изменении статуса, включая создание. Экспонируется как Booking.history (join, только если запрошено — паттерн unavailable_reasons).

State machine

BID → WAIT_PAYMENT → BOOKED → REJECTED — последовательно вперёд, «назад» нет, кроме прыжка в REJECTED из любого статуса. Прыжок через ступень вперёд (BID → BOOKED) разрешён. REJECTED — терминальный.

*OTA-защита: если booking.source === BookingSourceType.OTA, владелец не может перевести бронь в REJECTED вообще — только сама OTA-интеграция.

Права владельца по source: редактирование vs отмена

Раньше правило было плоским — «владелец может всё, кроме OTA». На практике владелец различает три типа заявок на своём объекте по-разному:

Прямое сравнение booking.source, без нового поля прав: editBooking — caller.id === housing.user_id AND source === MANUAL; отмена владельцем — caller.id === housing.user_id AND source !== OTA. Заявку, которую владелец завёл сам, он полностью контролирует; заявку от гостя не может подменить (исказило бы то, что гость реально запросил), но может отклонить; бронь с OTA не может тронуть вообще.

editBooking (даты, цена, контакты, заметка): только владелец, и только когда source === MANUAL (см. выше), в любом статусе кроме REJECTED. Поле status из BookingEditDto убирается — смена статуса только через отдельную мутацию.

UX подтверждения

Владелец не выбирает статус вручную — одно действие «Подтвердить» на заявке в BID:

Каскадная авто-отмена

1. Любая бронь на объекте переходит в BOOKED.
2. Сервис ищет на том же housing_id все другие брони не BOOKED/REJECTED, чьи даты пересекаются (exclusive-end, как в checkRangeOverlap).
3. Переводит их в REJECTED, reason_rejected = системный текст, changed_by_user_id = null.

Мутации

Гостевой флоу — переписывается

Форма выбора дат на самой странице объекта (лендинг) в этот флоу не входит и не меняется — важно только то, что происходит после перехода на confirm.vue.

Интеграция с чатом

BookingService.getBookingInfo сейчас фильтрует status: BOOKING — фильтр убирается, чат открывается с момента BID, доступен и после REJECTED. Проверка допуска в bid-chat-service's chat.service.ts меняется:

housing.user_id === user.id || booking.client_id === user.id

Права на списки

bookings.user_id = :userId
OR housing.user_id = :userId
OR bookings.client_id = :userId

Карта файлов

Переименование BOOKING → BOOKED — 10–12 мест только в TS-сравнениях статуса; pricing.sql не затронут.

Открытые вопросы

• Можно ли владельцу вручную привязать существующий client_id при ручном создании — по умолчанию оставляем возможность передать.
• Кросс-сервисная валидация существования client_id в user-service — можно отложить.
• Названия addBid/changeBookingStatus — рабочие.
• Где живёт флаг «принимает онлайн-оплату» (Housing или Booking) и как платёжный шлюз в будущем вызывает WAIT_PAYMENT → BOOKED — не решается сейчас.

Связанные документы

• Авторизация — техническая документация
• Ценообразование — техническая документация
• Гостевой флоу бронирования — этот же флоу переписывается