Техническое задание

1. Цель, границы и термины

Цель этапа — создать публичный сайт, личный кабинет клиента и административную систему InGame. Система должна вести бронирования, деньги и бизнес-статусы как единый источник правды, а amoCRM использовать для коммуникации с клиентом.

1.1. Входит в этап

• Публичный сайт, ЛК и административная система InGame.
• Миграция полной доступной истории текущего WordPress и переход основного домена.
• Реальные интеграции Montonio, amoCRM и Telegram-бота; email как клиентский канал уведомлений.
• Календарь, многобронирование, правила услуг, оплаты, отмены, сертификаты, цифровые бонусы, касса и отчёты.
• Настраиваемые роли, права, бизнес-правила, уведомления, контент и SEO.

1.3. Термины

2. Зафиксированные решения и роли

2.1. Зафиксированные решения

2.2. Пользователи и доступ

Каждый сотрудник работает только под персональной учётной записью. Общий логин на смену запрещён: любая скидка, возврат, кассовая правка, исключение из правила и изменение заказа должны быть связаны с конкретным человеком.

Владелец создаёт роли и назначает детальные права: просмотр/изменение расписания, изменения цен, скидки, возвраты, экспорт, отчёты, контент, интеграции, роли, аудит и ручные исключения.

3. Функциональные требования

3.1. Публичный сайт и контент

• На сайте доступны квесты, лаунжи, пакеты, услуги, товары, сертификаты, правила, контакты, FAQ и иные согласованные страницы на et/ru/en.
• Уполномоченный сотрудник редактирует контент, SEO-поля, URL, публикацию, переводы и изображения без изменения кода.
• Система сохраняет UTM-метки первого рекламного перехода и использует их в заказе и аналитике.

3.2. Заказ, корзина и многобронирование

• Корзина содержит единый заказ с позициями, фактической ценой на момент добавления, скидкой, языком, UTM, контактом клиента, оплатами и журналом изменений.
• Лаунж можно бронировать как в составе заказа с квестом, так и отдельно для мероприятия/помещения. Для него действуют те же проверки доступности и правила услуг.
• Каждая бронь хранит начало, окончание, ресурс, вместимость, количество игроков, статус и назначенного исполнителя/ответственного, если он известен.
• Система проверяет пересечения в транзакции БД. Две параллельные попытки занять одно время не создают двойную бронь.
• Менеджер может вручную менять состав и время заказа только в пределах прав. Исключения требуют причины и попадают в аудит.
• Для неоплаченной онлайн-брони действует настраиваемый срок удержания. До освобождения слота клиент получает уведомление.

3.3. Личный кабинет

• Регистрация по email и паролю; обязательные имя и телефон до создания брони. Подтверждается только email.
• Поддерживаются вход, выход, восстановление и смена пароля, смена email с повторным подтверждением, просмотр профиля и выход из активных сессий.
• После подтверждения email система связывает аккаунт с историческим клиентом по нормализованному email. При неоднозначности история не показывается автоматически: создаётся задача менеджеру на проверку/объединение.
• Клиент видит собственные заказы, статусы, оплаты, сертификаты, цифровые бонусы и заявки. В ЛК доступны разрешённые правилами изменения состава заказа.
• Клиент создаёт заявку на полную отмену заказа. Владелец задаёт срок, после которого отправка заявки запрещена. Решение по заявке принимает сотрудник.
• Частичное удаление одной игры/услуги и частичный возврат в стартовом релизе не выполняются автоматически до утверждения финансовой политики; интерфейс должен направлять такой случай менеджеру.

3.4. Расписание, услуги и исполнители

• Админка показывает календарь дня/недели, квесты, лаунжи, блокировки, статусы брони, исполнителя и операционные пометки.
• Уполномоченный сотрудник создаёт блокировки ресурса для ремонта, закрытия, частного события и иных причин.
• Для квеста/услуги настраиваются длительность, буфер, вместимость, допустимые ресурсы, поздние слоты и доступные каналы продажи.
• У каждой допуслуги задаются цена, публикация, переводы, изображение, обязательная предоплата, дедлайны добавления/отмены, совместимость, требования к пакету и несовместимости.
• Правила применяются одинаково на сайте, в ЛК и в админке. Пример: Dodo-пицца доступна только с лаунжем или пакетом дня рождения и не отменяется в день мероприятия; услуга другого поставщика может иметь дедлайн два дня.
• В брони/смене фиксируется исполнитель: кто проводил квест или анимацию. Данные доступны в отчёте и аудите для разбора ситуаций.

3.5. Оплаты, отмены, возвраты и касса

• Поддерживаются Montonio, наличные, карта на месте, банковский перевод и бесплатная корректировка только при отдельном праве.
• Montonio вызывается только серверной частью; webhook проходит проверку подлинности и идемпотентную обработку. Повторное внешнее событие не создаёт второй платёж или возврат.
• Возврат Montonio выполняет сотрудник с правом возврата отдельным действием: система показывает сумму, требует подтверждение и причину, затем фиксирует результат.
• Статусы заказа, брони, платежа, возврата и заявки на отмену хранятся отдельно. История денег не удаляется: корректировка создаёт новую запись.
• При закрытии смены система рассчитывает ожидаемые суммы из заказов и платежей. Сотрудник вводит фактические наличные и расходы с суммой, причиной и при необходимости файлом подтверждения.
• Если наличные не совпадают с ожидаемой суммой, система фиксирует дельту, требует пояснение, показывает её владельцу и отправляет уведомление по настраиваемому правилу.
• Статистика выделяет аномалии: заказ без достаточной оплаты, оплата без связанного заказа, ручная скидка, возврат, кассовая дельта и изменение цены.

3.6. Сертификаты, промокоды и цифровые бонусы

• Сертификат активируется только после подтверждённой оплаты. Электронный сертификат формируется и отправляется автоматически; физический создаёт отдельную задачу на выдачу или доставку.
• Для сертификата ведутся жизненный цикл и журнал: выпуск, оплата, отправка/выдача, применение, блокировка, перевыпуск, истечение срока и возврат. Срок действия и правила использования настраиваются владельцем.
• Список сертификатов позволяет найти будущую выдачу/доставку независимо от дня игры; обязательны статус, получатель, сумма, связанный заказ и дата действия.
• Промокоды и цифровые бонусы настраиваются по сумме/проценту, сроку, лимиту, минимальной сумме, товарам/услугам, совместимости, роли создателя и условиям выдачи.
• Повторный визит использует персональный цифровой бонус вместо бумажной карты. Любая ручная выдача требует разрешения, причины и остаётся в аудите.

3.7. Отчёты, коммуникация и уведомления

Владелец настраивает для каждого события включение, каналы, шаблон на трёх языках, Telegram-чаты/получателей и задержку. Система хранит журнал доставки и не создаёт дубликат при повторной попытке.

4. Техническая архитектура и данные

4.1. Целевая технология

4.2. Основные сущности БД

4.3. Ключевые ограничения данных

• Бронь ресурса сохраняется только в транзакции с проверкой пересечения. Ограничение на уровне PostgreSQL предотвращает конфликт даже при параллельных запросах.
• Цена, скидка, правило и состав заказа фиксируются снимком в момент применения. Изменение каталога не переписывает историю.
• Внешние callbacks и задачи имеют ключ идемпотентности; один webhook нельзя применить дважды.
• Аудит, платежи и кассовые записи не удаляются пользовательскими операциями. Для корректировки используются новые записи, связываемые с исходной.

5. Интеграции, миграция и запуск

5.1. Montonio

• Создание платёжной ссылки, обработка результата и возврат выполняются серверной частью по официальному API провайдера.
• Webhook проверяется до изменения данных. В журнале сохраняются внешний идентификатор, результат, время, ошибка и связь с внутренней оплатой.
• Если Montonio недоступен, заказ сохраняется в понятном статусе, а повтор/проверка доступна сотруднику; данные не теряются.

5.2. amoCRM

• На один внутренний заказ создаётся или обновляется одна сделка amoCRM и один связанный контакт клиента.
• Передаются клиентские контакты, язык, все брони со временем, лаунжи, услуги, еда, товары, сумма, оплаты, промокоды, отмены, комментарии для общения и ссылка в InGame.
• Отправка идёт через outbox с повторными попытками. Ошибка amoCRM не блокирует создание/изменение заказа; сотрудник видит дату последней успешной синхронизации и текст ошибки.
• Изменения этапа сделки amoCRM не меняют бизнес-статусы InGame автоматически.

5.3. Telegram и email

Telegram-бот используется для операционных сообщений. Email используется для клиента и подтверждения аккаунта. Для обоих каналов обязательны очередь, повторные попытки, журнал доставки, защита от дублей и настраиваемые шаблоны.

5.4. Миграция WordPress

• Если файл или запись невозможно безопасно связать с целевой сущностью, он не теряется молча: попадает в import_quarantine с причиной и путём решения.
• Перед запуском формируется отчёт сверки: количество и контрольные суммы по сущностям, сумма оплат, выборка сложных заказов, дубли клиентов и невыданные сертификаты.
• Пробная миграция не изменяет источник. Финальная миграция переносит дельту за согласованное окно и повторяет сверку.
• Карта 301-редиректов старых URL и инвентаризация контента обязательны до переключения домена.

5.5. Поэтапный запуск

1. Подготовить тестовый контур, секреты интеграций, хранилище, мониторинг и резервное копирование.
2. Выполнить пробную миграцию, отчёт сверки и исправление импортных исключений.
3. Провести интеграционные и приёмочные тесты с Montonio, amoCRM, Telegram, email и реальными сценариями ролей.
4. Открыть ограниченный тестовый доступ сотрудникам, собрать ошибки и зафиксировать готовность к запуску.
5. В согласованное окно перенести финальную дельту, переключить домен, включить мониторинг и оставить WordPress только для архива.

6. Безопасность, качество и критерии приёмки

6.1. Безопасность и надёжность

• Пароли хранятся только в криптографическом хеше. Секреты интеграций доступны исключительно серверной части через переменные окружения.
• Регистрация, вход и восстановление пароля имеют лимиты попыток, защиту от перебора, срок действия токенов и журнал событий безопасности.
• Смена email требует повторного подтверждения. Сессии имеют срок действия и могут быть завершены пользователем/администратором.
• Проверка прав выполняется на сервере в каждом действии и API, а не только скрытием кнопок интерфейса.
• Должны быть согласованы и реализованы: политика хранения/удаления персональных данных, выгрузка данных по запросу клиента, отзыв маркетингового согласия и разграничение финансового аудита от удаления профиля.
• База и файлы резервируются; восстановление проверяется по расписанию. Перед миграцией устраняется риск нехватки места на текущем сервере.
• Все даты работают в часовой зоне площадки, которая задана настройкой (целевое значение согласуется до запуска).

6.2. Критерии приёмки

1. Клиент на et/ru/en создаёт гостевой заказ, оплачивает его через Montonio, получает сервисное письмо, регистрируется и видит свою историю после подтверждения email.
2. Клиент или менеджер добавляет в один заказ два квеста, лаунж и услуги. Система показывает/сохраняет только не конфликтующую комбинацию; конкурентный запрос не создаёт двойную бронь.
3. Лаунж успешно бронируется как отдельное мероприятие без квеста, а связанные услуги применяют настроенные условия.
4. Менеджер изменяет заказ вручную только с выданным правом; исключение из правила содержит причину, автора и появляется в аудите.
5. Заявка на отмену после настроенного дедлайна не создаётся. Менеджер подтверждает отмену, затем отдельным действием запускает возврат Montonio; повторный webhook не создаёт вторую операцию.
6. Сертификат становится доступным только после успешной оплаты; электронный направляется получателю, физический не пропадает из очереди выдачи/доставки.
7. Владелец создаёт новую роль и назначает только просмотр расписания. Пользователь с этой ролью не видит финансы, настройки, экспорт и чужие персональные данные.
8. Каждый сотрудник входит под персональным аккаунтом. Скидка, возврат, кассовая правка и изменение цены позволяют найти автора и время.
9. При закрытии смены фактическая наличность сверяется с ожидаемой. Дельта требует пояснения, отражается в статистике аномалий и отправляется по настроенному уведомлению.
10. Владелец настраивает два разных правила Telegram: отмены в чат менеджеров и дневной отчёт в личный чат. Проверены канал, получатель, задержка, отсутствие дубля и журнал доставки.
11. В статистике владелец фильтрует выручку и количество игр/лаунжей/анимаций по периоду и UTM; сотрудник видит только свой дневной отчёт.
12. Миграция имеет отчёт сверки по клиентам, заказам, броням, оплатам, сертификатам, промокодам, журналу и медиа; все исключения перечислены и согласованы.
13. После переключения старые публичные URL дают согласованный 301-редирект, WordPress не принимает новые рабочие заказы и остаётся защищённым архивом.