CRITICAL
Действия админа
- Войти в админку и открыть основной dashboard или первый рабочий раздел.
- Проверить список requests, bookings, сообщения и finance view хотя бы на уровне открытия страниц.
- Передать клиенту подтверждение, что админская зона готова принимать новые сущности.
Пока ждёшь клиента
- Обновить админку и убедиться, что сессия переживает reload.
- После logout попробовать открыть прямой URL админки и подтвердить, что защита работает.
Подсценарий 1A. Ошибки входа
- Попробовать невалидные данные логина.
- Если доступен reset flow для админа, проверить его на тестовом аккаунте.
Ожидание: ошибочный вход не заводит в систему и не оставляет полусессию.
Подсценарий 1B. Protected route после logout
- Выйти из админки.
- Открыть прямую ссылку на внутренний раздел.
Ожидание: административные страницы не остаются открытыми после очистки сессии.
CRITICAL
Действия админа
- По мере прихода клиентских заявок находить Request A, B и C через список, поиск или фильтры.
- Открыть A, B и C из списка и убедиться, что каждая карточка открывается отдельно и не смешивается с соседними сущностями.
- Проверить, что несколько request-ов одного клиента не ломают список и навигацию.
- До старта коммуникации не менять request-ы без синхронизации с клиентом.
Пока ждёшь клиента
- Обновлять список и следить, не появляются ли дубль-строки после refresh.
- Проверить поиск по email, id и базовым статусам.
Подсценарий 2A. Открытие карточек из списка
- Открыть все три карточки из списка по очереди.
- Убедиться, что переходы работают стабильно и не ведут в соседнюю сущность.
Ожидание: админ открывает именно ту карточку, которую выбрал в списке.
Подсценарий 2B. Refresh и duplicate visibility
- Обновить список после появления новых request-ов.
- Проверить, что одинаковые сущности не отображаются дважды.
Ожидание: refresh не создаёт ощущение дубликатов и не теряет новые записи.
HIGH
Действия админа
- Открыть Request A и отправить первое рабочее сообщение клиенту.
- Дождаться клиентского ответа и убедиться, что он читается в той же истории и в правильном порядке.
- Открыть Request B и обработать change request либо спровоцировать его уточняющим сообщением.
- После каждого действия заново открыть карточку из списка и сравнить timeline.
- Оставить Request C нетронутым, чтобы позже использовать его как контрольную сущность.
Пока ждёшь клиента
- Проверять timestamps и порядок сообщений после refresh.
- Сверять, что статус карточки соответствует последнему сообщению или change request.
Подсценарий 3A. Повторный ответ админа
- После первого ответа клиента отправить ещё одно админское сообщение.
- Проверить, что порядок thread не ломается.
Ожидание: коммуникация остаётся последовательной и не превращается в набор разрозненных сообщений.
Подсценарий 3B. Reload после client changes
- Сразу после change request обновить страницу.
- Проверить, что история и статус перечитались корректно.
Ожидание: админка не требует ручного восстановления состояния после refresh.
Подсценарий 3C. Пустые и длинные сообщения
- Проверить, блокируется ли пустая отправка.
- Отправить длинное сообщение и убедиться, что оно не ломает layout.
Ожидание: административный communication UI устойчив на неидеальных вводах.
CRITICAL
Действия админа
- Сконвертировать Request A в Booking A и отправить первую версию предложения.
- После client request changes обновить предложение A и отправить revised version, не создавая лишних дублей.
- Сконвертировать Request B в Booking B и дождаться чистого client approve.
- Проверить, что Booking A и B открываются из общего списка и остаются связаны со своими исходными request-ами.
- Не трогать Request C, если он не нужен как контрольная ветка позже.
Пока ждёшь клиента
- Переоткрывать A и B из списка booking-ов после каждого крупного действия.
- Проверять, что convert action не создаёт дубль при refresh или повторном открытии экрана.
Подсценарий 4C. Повторное открытие booking-ов
- После approve выйти в список booking-ов.
- Заново открыть A и B и сверить статусы.
Ожидание: booking-и стабильно доступны и не исчезают после одного просмотра.
CRITICAL
Действия админа
- После успешной оплаты Booking A открыть карточку, finance view и убедиться, что paid state дошёл до админки.
- Во время failed attempt по Booking B проверить, что статус не становится paid преждевременно.
- После успешного retry по B повторно открыть карточку и finance row.
- Открыть доступные документы.
- Проверить, что booking-и по-прежнему открываются из списка и связаны с корректными request-ами.
Пока ждёшь клиента
- Обновлять карточки после client payment flow и смотреть, когда приходит финальный sync.
- Проверять, нет ли дублей строк в finance view после повторных открытий.
Подсценарий 5A. Finance row consistency
- Сравнить booking card и finance row по A и B.
- Проверить совпадение суммы, статуса и идентификатора.
Ожидание: finance-раздел не расходится с карточкой booking-а.
Подсценарий 5B. Повторное открытие документов
- Открыть документ сразу после обновления статуса.
- Открыть тот же документ позже, из другого раздела.
Ожидание: ссылки на документы стабильны и не становятся битым артефактом.
Подсценарий 5C. Webhook/reload stability
- Во время платёжного sync обновить админскую страницу.
- Проверить, что конечный статус читается корректно после refresh.
Ожидание: платёжный результат переживает reload и не требует ручного ресета админки.
CRITICAL
Действия админа
- Открыть Booking B после клиентского cancellation request и проверить карточку, timeline и общий список booking-ов.
- Использовать фильтр статусов и убедиться, что booking находится по cancellation-related состоянию.
- Если в текущей сборке есть обязательный шаг обработки отмены со стороны админа, выполнить его один раз и проверить, что статус Booking B обновился без дублей.
- Проверить, что Booking A не затронут cancellation-логикой B.
Пока ждёшь клиента
- Обновлять список booking-ов и карточку B, чтобы проверить сохранность derived status после refresh.
- Сверять состояние в списке, карточке и finance-related экранах после reload.
Подсценарий 6A. Duplicate protection
- После одного действия обработки отмены переоткрыть карточку.
- Проверить, что система не предлагает создать второй одинаковый cancellation flow без причины.
Ожидание: отмена не плодит дубликаты и не создаёт повторяющиеся операционные шаги.
Подсценарий 6C. Статус в разных представлениях
- Сравнить cancellation status в списке booking-ов, карточке и finance-related view.
- После reload повторить сравнение.
Ожидание: важный административный статус показывает одно и то же значение во всех рабочих местах.
HIGH
Действия админа
- Если в админке есть outbox, logs или email history, проверить уведомления на регистрацию, reset, booking/proposal, payment, cancellation и change email.
- Открыть user card Client A и убедиться, что новый email после клиентского изменения сохранился корректно. Если сборка позволяет, выполнить один контролируемый admin-side тест изменения email или resend verification на отдельном тестовом аккаунте.
- Если админка поддерживает password reset или задание нового пароля пользователю, прогнать этот поток на тестовом аккаунте и синхронно с клиентом проверить, что старый доступ больше не работает.
- Удалить или деактивировать тестовый пользовательский аккаунт из админки, подтвердить warning texts и проверить, что связанные request-ы и booking-и остаются читаемыми в отчётном виде.
- После удаления обновить users list и поиск и убедиться, что аккаунт больше не считается активным для входа.
Пока ждёшь клиента
- Дождаться подтверждения клиента по email, password и account deletion эффектам на фронте.
- Обновлять user card, users list и поиск, чтобы убедиться, что изменения переживают reload.
Подсценарий 7A. Email-аудит
- Проверить, что все ключевые системные письма отображаются в журналах или history, если такой модуль существует.
- Сверить, что письма привязаны к правильному пользователю и событию.
Ожидание: email-канал прозрачен для диагностики и не теряет события.
Подсценарий 7B. Смена пароля пользователя
- Запустить admin-side reset или смену пароля для тестового пользователя.
- Убедиться, что старый пароль перестаёт быть валидным, а новый путь входа подтверждён клиентом.
Ожидание: админская ротация пароля не оставляет два рабочих секрета одновременно.
Подсценарий 7C. Удаление аккаунта пользователя
- Удалить или деактивировать тестовый аккаунт через админский интерфейс.
- Проверить, что аккаунт больше не доступен для логина, но история сущностей остаётся пригодной для отчёта.
Ожидание: удаление пользователя не ломает связанные операционные данные и честно закрывает доступ.