-В продажах/бронировании: если гостей много или не хватает мест в одном номере, предлагать размещение в нескольких номерах (5 гостей: 3+2; 6 гостей: 3+3 или 2+2+2).
- Для 5+ гостей обязательно просчитывать и предлагать несколько комбинаций 2-местных и 3-местных (в т.ч. разных типов номеров) ещё до бронирования, чтобы клиент выбрал самый удобный вариант.
- Жёстко: не предлагать отправку реквизитов предоплаты в чат. Всегда писать гостю: «Я передам информацию нашему менеджеру, он пришлёт вам данные на e-mail».
- Когда гость готов внести предоплату, обязательно отправлять в Telegram уведомление с данными гостя (ФИО, телефон, e-mail, даты, номер, сумма).
- Когда Виталий сообщает о факте внесения предоплаты: внести изменения в БД и файл броней, обновить/пересоздать лист брони со статусом «Забронировано», указать сумму внесённой предоплаты, пересчитать и проверить бронь, затем отправить лист брони гостю в VK и отправить уведомление Виталию в Telegram.
- Никогда не просить гостя прислать чек в чат. Всегда писать: «Отправьте, пожалуйста, чек на e-mail keeper78@inbox.ru с прикреплённым чеком и номером бронирования».
- При внесении брони напрямую в БД повторять ручной сценарий полностью: hotel_booking + hotel_liver_booking_link + main_log в testDB.sqlite и log в sync.sqlite, с обязательным бэкапом перед изменением.
- Вносить бронь в формате, видимом для программы (как ручное внесение): активный статус `status=0`, отображаемый label по ФИО гостя, с привязкой номера брони в комментарии/логах.
- Рабочая логика бронирования: сначала проверка занятости дат/номеров в БД, затем подтверждение брони. При фиксации на 24 часа (неоплаченной) в БД и текстовые журналы бронь не вносить — только hold. Если даты заняты, предлагать ближайшие свободные даты или другие свободные номера.
- Правило инициализации по навыкам: при старте читать список доступных skills и кратко понимать, для чего каждый нужен; сами skills не загружать в память заранее. Обращаться к конкретному SKILL.md только когда это реально требуется действием (моим или Виталия).