Law/context/13_role_flows_test_matrix.md

# Матрица User Flow для Тестирования Платформы (CLIENT / LAWYER / ADMIN)

## Назначение
Этот файл описывает полный набор пользовательских сценариев для тестирования платформы через веб-интерфейс.
Используется как:
1. чеклист ручной приемки,
2. источник для e2e/интеграционных сценариев,
3. карта corner cases по ролям.

## Общие правила проверки
1. Все ключевые сценарии проверять через UI (не только по API).
2. Для каждого сценария проверять:
   - видимость данных по роли,
   - корректность уведомлений/непрочитанного,
   - записи в истории статусов/чата,
   - отсутствие утечки служебной/финансовой информации клиенту.
3. Для статусов:
   - `важная дата` видна клиенту, юристу и администратору,
   - для юриста/администратора это дедлайн текущего статуса,
   - смена статуса логируется вместе с `важной датой` и комментарием.
4. Для файлов:
   - проверять и успешный сценарий, и ошибки (размер, MIME, предпросмотр, поврежденный файл).

## Тестовые роли и данные (рекомендуемые)
1. `ADMIN`: `admin@example.com` / `admin123`
2. `LAWYER #1`: основной юрист (назначенные заявки)
3. `LAWYER #2`: другой юрист (для проверок запрета доступа к чужим данным)
4. `CLIENT #1`: новый клиент (новый номер телефона)
5. `CLIENT #2`: второй клиент (для проверки изоляции JWT/заявок)

## CLIENT (Пользователь / Заказчик)

### C01. Просмотр лендинга и создание заявки (happy path)
1. Открыть лендинг.
2. Открыть модальную форму создания заявки.
3. Заполнить:
   - ФИО,
   - телефон,
   - тему,
   - описание.
4. Пройти OTP-подтверждение телефона.
5. Создать заявку.
6. Проверить:
   - выдан уникальный номер заявки,
   - создается запись клиента (`client`) и связь с заявкой,
   - клиент не видит служебные поля (ставка, стоимость, внутренние ID, ответственные ID, финансовые поля).

### C02. Повторный вход в клиентский контур по номеру/OTP
1. На лендинге нажать кнопку перехода к работе с заявкой.
2. Если нет JWT (новое устройство/браузер), пройти OTP.
3. Открыть страницу работы с заявкой.
4. Проверить:
   - доступ только к своим заявкам,
   - после авторизации создается 7-дневный JWT/сессия устройства,
   - повторный вход на том же устройстве не требует OTP до истечения срока.

### C03. Переключение между заявками клиента
1. Создать 2+ заявки на один телефон.
2. Открыть клиентский кабинет.
3. Переключаться между заявками в UI.
4. Проверить:
   - отображаются только заявки этого клиента,
   - корректно обновляются статус, чат, файлы, важная дата, уведомления,
   - переход не ломает состояние JWT/авторизации.

### C04. Просмотр карточки заявки (видимость данных)
1. Открыть заявку в клиентском кабинете.
2. Проверить, что видны:
   - номер заявки,
   - тема,
   - статус,
   - важная дата (дедлайн),
   - история/маршрут статусов,
   - чат,
   - файлы,
   - запросы дополнительных данных.
3. Проверить, что НЕ видны:
   - ставка юриста,
   - внутренние финансовые поля,
   - служебные ID,
   - служебные комментарии/системная информация, не предназначенная клиенту.

### C05. Чат клиент <-> юрист (happy path)
1. Клиент отправляет сообщение юристу.
2. Юрист отвечает.
3. Клиент обновляет/переоткрывает заявку.
4. Проверить:
   - сообщения отображаются в стиле чата,
   - метки времени/даты корректны,
   - непрочитанные индикаторы появляются и сбрасываются после открытия заявки,
   - история сообщений сохраняется.

### C06. Загрузка файлов клиентом (happy path)
1. В карточке заявки/чате прикрепить файл.
2. Отправить сообщение с файлом.
3. Проверить:
   - файл загружается,
   - появляется в чате и во вкладке файлов,
   - доступен предпросмотр/скачивание,
   - размер учитывается в лимитах заявки.

### C07. Запрос дополнительных данных от юриста (частичное заполнение)
1. Юрист создает `Запрос` с несколькими полями.
2. Клиент открывает сообщение `Запрос`.
3. Заполняет часть полей, сохраняет.
4. Повторно открывает запрос и дозаполняет остальное.
5. Проверить:
   - заполненные поля отмечаются и зачеркиваются в чате,
   - незаполненные остаются активными,
   - после полного заполнения запрос сворачивается и меняет цвет/состояние.

### C08. `file`-поле в запросе дополнительных данных
1. Юрист создает запрос с полем типа `file`.
2. Клиент загружает файл в это поле.
3. Проверить:
   - файл реально загружается как attachment,
   - поле считается заполненным,
   - файл доступен в файлах заявки и в контексте запроса,
   - юрист видит, что запрос выполнен.

### C09. Оповещения клиента
1. Юрист меняет статус.
2. Юрист отправляет сообщение.
3. Юрист загружает файл.
4. Клиент открывает кабинет.
5. Проверить:
   - есть визуальные индикаторы новых событий,
   - открытие заявки сбрасывает непрочитанное состояние,
   - важная дата обновляется при смене статуса.

### C10. Терминальный статус (завершение заявки)
1. Юрист/админ переводит заявку в терминальный статус.
2. Клиент открывает заявку.
3. Проверить:
   - терминальный статус отображается корректно,
   - маршрут/история статусов содержит финальную запись,
   - важная дата по финальному статусу отображается.

### C11. Ошибка загрузки файла (корнер-кейсы)
Проверить UI-реакцию и корректный текст ошибки:
1. Слишком большой файл (>25MB).
2. Превышение суммарного лимита по заявке (>250MB).
3. Обрыв сети/ошибка presigned upload.
4. Неподдерживаемый или некорректный MIME.
5. Проверить:
   - пользователь видит понятную ошибку,
   - UI не зависает,
   - частично неуспешная отправка не ломает чат,
   - дубликаты/битые attachments не создаются.

### C12. Слишком длинное сообщение / некорректное сообщение
1. Отправить очень длинный текст (выше backend-лимита, если установлен).
2. Отправить пустое сообщение.
3. Отправить сообщение из пробелов.
4. Проверить:
   - понятная ошибка в UI,
   - ничего лишнего в чат не попадает,
   - состояние формы остается консистентным.

### C13. Предпросмотр файлов (валидный / невалидный)
1. Валидный `pdf`, `jpg`, `mp4`, `txt`.
2. Невалидный PDF (файл с MIME `application/pdf`, но без `%PDF-`).
3. `.txt` с кривым MIME (`application/pdf`).
4. Проверить:
   - валидные файлы открываются,
   - невалидный PDF дает fallback (понятное сообщение / текстовый предпросмотр),
   - `.txt` открывается текстом даже при кривом MIME.

### C14. Безопасность доступа клиента (изоляция)
1. Открыть чужой номер заявки.
2. Использовать JWT клиента #1 для заявки клиента #2.
3. Попробовать открыть прямые URL файлов чужой заявки.
4. Проверить:
   - доступ запрещен,
   - нет утечки метаданных.

## LAWYER (Юрист)

### L01. Вход и видимость заявок
1. Войти как юрист.
2. Открыть список заявок.
3. Проверить видимость:
   - свои заявки,
   - неназначенные заявки,
   - отсутствие чужих назначенных заявок.

### L02. Claim неназначенной заявки
1. В списке или в канбане выбрать неназначенную заявку.
2. Нажать `Взять в работу`.
3. Проверить:
   - заявка назначается текущему юристу,
   - в канбане/таблице обновляется исполнитель,
   - claim логируется (audit),
   - другой юрист больше не может ее claim'ить.

### L03. Канбан: просмотр и работа с карточками
1. Открыть `Канбан`.
2. Проверить:
   - группировка по группам статусов,
   - карточки содержат ключевые поля (номер, клиент, тема, дедлайн/важная дата, индикаторы новых сообщений/файлов),
   - горизонтальная прокрутка внутри блока, без растягивания страницы.

### L04. Канбан: drag&drop смена статуса (однозначная группа)
1. Перетащить карточку в колонку, где целевая группа сопоставляется с одним статусом.
2. Проверить:
   - статус меняется,
   - важная дата проставляется по умолчанию (`+3 дня`), если не задана явно,
   - изменение отображается в карточке и в истории статусов.

### L05. Канбан: drag&drop в группу с несколькими статусами
1. Перетащить карточку в колонку, где в группе >1 статуса.
2. Проверить:
   - открывается карточка заявки / модалка смены статуса,
   - доступны только статусы соответствующей группы,
   - можно выбрать конкретный статус и важную дату.

### L06. Смена статуса из карточки заявки (happy path)
1. Открыть карточку заявки.
2. Нажать кнопку смены статуса.
3. Выбрать новый статус, указать важную дату, добавить комментарий и файл.
4. Отправить.
5. Проверить:
   - статус заявки обновился,
   - важная дата изменилась,
   - запись появилась в истории статусов,
   - комментарий/файл попали в чат.

### L07. Терминальный статус (закрытие заявки юристом)
1. Юрист переводит заявку в терминальный статус.
2. Проверить:
   - статус обновлен,
   - заявка считается завершенной в dashboard/метриках,
   - история статусов содержит терминальный этап.

### L08. История статусов в модалке смены статуса
1. Открыть модалку смены статуса для заявки с несколькими сменами статусов.
2. Проверить:
   - список прокручивается внутри фиксированного блока,
   - новые записи сверху, старые снизу,
   - видны дата назначения, важная дата, длительность нахождения, комментарий (если есть).

### L09. Важные даты (дедлайн) у юриста
1. Сменить статус без указания даты.
2. Проверить автоподстановку `+3 дня`.
3. Сменить статус с ручной датой.
4. Проверить:
   - дедлайн отображается в карточке заявки,
   - дедлайн отображается в канбане,
   - цвет дедлайна в канбане соответствует сроку.

### L10. Чат и файлы юриста
1. Отправка сообщений клиенту.
2. Отправка файлов.
3. Отправка файла+сообщения.
4. Drag&drop файлов в чат.
5. Проверить:
   - сообщения/файлы видит клиент,
   - непрочитанные индикаторы работают,
   - предпросмотр/скачивание работают.

### L11. Запрос дополнительных данных (шаблоны)
1. Открыть модалку `Запросить`.
2. Выбрать существующий шаблон.
3. Проверить автозагрузку полей шаблона в таблицу (без дубликатов).
4. Добавить поле из справочника.
5. Создать новое поле через тот же инпут.
6. Сохранить шаблон:
   - новый,
   - перезапись своего.
7. Проверить:
   - чужой шаблон нельзя перезаписать (UI + backend),
   - badge/tooltip соответствуют статусу шаблона.

### L12. Ограничения редактирования заполненных клиентом доп.данных
1. После заполнения клиентом открыть запрос в чате.
2. Проверить, что юрист НЕ может:
   - менять название поля,
   - тип,
   - порядок,
   - удалять заполненное поле.
3. Проверить backend-защиту (через UI негативный сценарий / при попытке сохранить).

### L13. Ограничения по правам (чужая заявка)
1. Попробовать открыть/изменить чужую назначенную заявку.
2. Попробовать сменить статус чужой заявки.
3. Попробовать загрузить файл/написать сообщение в чужую заявку.
4. Ожидание: запрет доступа/операции.

### L14. Финансовые ограничения
1. Юрист не должен иметь возможность менять запрещенные финансовые поля через CRUD заявки.
2. Юрист не может подтверждать оплату счета (`PAID`).
3. Проверить UI/API сообщения об ошибке.

## ADMIN (Администратор)

### A01. Вход и доступ ко всем разделам
1. Войти как администратор.
2. Проверить доступ:
   - Обзор,
   - Канбан,
   - Заявки,
   - Счета,
   - Справочники,
   - `availableTables` по прямой ссылке.

### A02. Справочник пользователей (CRUD)
1. Создать юриста:
   - имя, email, пароль,
   - роль,
   - основная тема,
   - дополнительные темы,
   - ставка по умолчанию,
   - процент,
   - телефон,
   - аватар.
2. Отредактировать пользователя.
3. Деактивировать/активировать.
4. Проверить:
   - данные сохраняются,
   - аватар/инициалы отображаются корректно,
   - роль и RBAC применяются.

### A03. Справочники статусов и групп статусов
1. Создать/редактировать группы статусов.
2. Создать/редактировать статусы:
   - группа,
   - терминальность,
   - kind (обычный / счет / оплачено).
3. Проверить:
   - канбан строится по группам,
   - статусы появляются в свободном выборе смены статуса.

### A04. Таблицы в справочниках и `availableTables`
1. Открыть `/admin.html?section=availableTables`.
2. Включать/выключать таблицы.
3. Проверить:
   - неактивные таблицы исчезают из списка справочников,
   - активные появляются без фронтовой доработки (универсальное отображение),
   - `clients` видны в справочниках, если таблица активна.

### A05. Заявки: полный CRUD и ручное управление
1. Создать заявку вручную.
2. Привязать существующего клиента.
3. Создать нового клиента через форму заявки (если нет в списке).
4. Изменить тему/описание/исполнителя/стоимость.
5. Проверить:
   - `client_id` корректно проставляется,
   - стоимость заявки видна админу/юристу, скрыта клиенту.

### A06. Смена статуса заявки (с важной датой)
1. Открыть карточку заявки.
2. Через модалку смены статуса:
   - выбрать любой статус,
   - указать важную дату,
   - добавить комментарий/файл.
3. Проверить:
   - изменения видны клиенту/юристу/админу,
   - история статусов содержит важную дату и комментарий.

### A07. Администратор может корректировать заполненные доп.данные
1. После заполнения клиентом доп.данных открыть запрос.
2. Удалить/изменить заполненную строку (если требуется).
3. Проверить:
   - операция разрешена админу,
   - изменения консистентны.

### A08. Счета и оплаты (happy path)
1. Создать счет вручную.
2. Проверить формирование PDF.
3. Перевести в `Оплачен`.
4. Проверить:
   - дата оплаты проставляется,
   - данные видны в списке счетов,
   - юрист видит свои счета, админ — все.

### A09. Billing через статусы
1. Перевести заявку в billing-статус (если используется `INVOICE` / `PAID`).
2. Проверить:
   - срабатывает логика счетов/оплаты,
   - сумма/зарплата отражается в дашборде.

### A10. Dashboard администратора
Проверить плитки и метрики:
1. Новые / в работе / и др. статусы.
2. Выручка за месяц.
3. Расходы (зарплата юристов) за месяц.
4. Карточки загрузки юристов:
   - активные,
   - новые,
   - закрыто,
   - сумма,
   - зарплата.
5. Модалка статистики юриста:
   - фиксированные хедеры,
   - таблица активных заявок,
   - сумматоры внизу,
   - корректные переходы в карточки заявок.

### A11. Безопасность / аудит / доступы
1. Проверка доступа к файлам S3 по ролям.
2. Предпросмотр PDF/файлов через iframe/same-origin.
3. Проверка аудита действий (security audit / audit log).
4. Проверка, что ПДн и финансовые данные не уходят в публичный контур.

### A12. Corner cases администратора
1. Ошибки сохранения (невалидные поля, несуществующие ссылки).
2. Одновременное редактирование (refresh после сохранения).
3. Попытка удалить сущность, на которую есть ссылки.
4. Некорректные даты/числа в универсальных формах.
5. Проверить понятные ошибки и отсутствие “битого” состояния UI.

## Межролевые интеграционные сценарии (сквозные)

### X01. Полный цикл заявки (client -> lawyer -> terminal)
1. Клиент создает заявку.
2. Юрист берет в работу.
3. Юрист ведет чат, запрашивает данные/файлы.
4. Клиент заполняет запрос.
5. Юрист меняет статусы, выставляет важные даты.
6. Юрист завершает заявку терминальным статусом.
7. Проверить весь таймлайн и видимость по ролям.

### X02. Цикл со счетом и оплатой
1. Клиент создает заявку.
2. Юрист/админ переводит в статус выставления счета.
3. Админ формирует/подтверждает оплату счета.
4. Проверить:
   - счет виден в заявке и в списке счетов,
   - статус оплаты влияет на финансовые метрики,
   - зарплата юриста считается после `Оплачено`.

### X03. Непрочитанные события и уведомления
1. Создать набор событий: статус, сообщение, файл.
2. Проверить отображение индикаторов:
   - в списках,
   - в канбане,
   - в карточке заявки.
3. Проверить сброс после открытия заявки соответствующей ролью.

### X04. Ограничения прав и изоляция
1. CLIENT не видит служебные/финансовые поля.
2. LAWYER не видит/не меняет чужие заявки.
3. LAWYER не подтверждает оплату.
4. LAWYER не редактирует заполненные клиентом доп.данные.
5. ADMIN имеет доступ ко всем данным и операциям.

## Corner Cases (общий список для обязательного покрытия)
1. Пустые поля / пробельные значения.
2. Слишком длинные тексты сообщений / комментариев.
3. Файлы:
   - >25MB,
   - превышение 250MB на заявку,
   - невалидный PDF,
   - `.txt` с кривым MIME.
4. Повторные клики / double-submit.
5. Потеря сети во время upload/send/status-change.
6. Истекший JWT / отсутствие OTP.
7. Конфликт назначения заявки (claim race).
8. Удаление/изменение связанной сущности (клиент/статус/пользователь).
9. Переключение между заявками/разделами при открытых модалках.

## Рекомендация по автоматизации (e2e backlog)
Приоритетно выделить в отдельные Playwright-сценарии:
1. `public_client_notifications_flow`
2. `lawyer_status_change_modal_flow` (важная дата + комментарий + файл)
3. `kanban_multi_status_group_flow` (drag&drop -> выбор статуса)
4. `admin_finance_billing_dashboard_flow`
5. `client_file_upload_errors_flow`
6. `rbac_negative_flows` (client/lawyer/admin)