apps/landing + apps/front · Техническая документация
проверено вручную по всем веткам

Лендинг → регистрация/логин → подтверждение

Механизм редиректа между apps/landing и apps/front, сохраняющий параметры брони через весь флоу авторизации — включая email-подтверждение в отдельной вкладке.

Механизм редиректа

Отсутствие черновой брони

BookingStatusType.BID заведён в @shared/src/catalogs/booking/status.ts, но в текущей (утверждённой) реализации гостевого флоу нигде не используется — мёртвый код/задел на будущее (см. «Новый жизненный цикл бронирования» — там BID становится рабочим статусом). Это значит: даты объекта остаются доступными для других всё время, пока гость проходит регистрацию/подтверждение и редактирует поля на confirm.vue. Как только addBooking реально выполнится (status: 'BOOKING' жёстко зашит в confirm.vue's onSave()), даты сразу становятся занятыми — проверено эмпирически.

unavailable_reasons во время редактирования (исправленный гэп)

confirm.vue живо (без debounce, на каждое изменение полей) перезапрашивает housingWithPrice. Раньше эта query шла через HousingService.findOneWithPrice, вызывающую только addSelections, а не assertBookable — недопустимые варианты (питомцы на объекте с allow_animals=false, недопустимый возраст ребёнка, бронь короче min_night_count) никак не отображались во время редактирования, ошибка вылезала только по факту нажатия «Оплатить», сырой непереведённой английской строкой.

Исправлено:

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