# Сценарий экспертной проверки

Документ описывает короткий ручной сценарий проверки установленного экземпляра
AWatch-rus. Он рассчитан на чистый тестовый стенд после установки по
`docs/INSTALL_FOR_EXPERT_RU.md`.

## Предусловия

- серверный экземпляр установлен и запущен;
- доступен операторский web UI или gateway URL тестового стенда;
- доступен тестовый Windows endpoint с установленными collectors;
- задан тестовый пользователь, например `HOST-EXAMPLE\user1`;
- Grafana/отчеты включены, если они входят в проверяемый состав поставки;
- используются только тестовые файлы и тестовые данные.

## 1. Вход в web-интерфейс

Действия:

1. Открыть операторский портал по URL тестового стенда.
2. Войти под тестовой учетной записью администратора или оператора.
3. Открыть карточки ActivityWatch, Инциденты ИБ, отчеты и Grafana.

Ожидаемый результат:

- портал открывается без ошибки `500/502/503`;
- карточки не ведут на личные адреса разработчика;
- ссылки используют адреса тестового стенда;
- Grafana/ActivityWatch доступны через опубликованные переходы.

## 2. Проверка базового статуса контура

Действия на сервере:

```bash
detmir-check --json
detmir-status --json
systemctl --failed --no-pager
```

Ожидаемый результат:

- `detmir-check` возвращает JSON без критичных ошибок;
- `detmir-status` показывает агрегированный статус установленного контура;
- `systemctl --failed` не показывает критичных units AWatch-rus.

## 3. Проверка clipboard/USB/print сигналов

Действия на тестовом Windows endpoint:

1. Скопировать тестовую строку в clipboard.
2. Подключить тестовый USB-носитель или выполнить имитацию USB-события,
   предусмотренную стендом.
3. Отправить тестовый документ на тестовый printer/PDF-printer.

Ожидаемый результат:

- в ActivityWatch появляются события endpoint/file operations;
- в операторском портале или Grafana видны новые сигналы по тестовому host;
- события содержат тестовые metadata и не содержат секретов стенда.

## 4. Генерация DLP-инцидента

Действия:

1. Создать тестовый файл с явно тестовой строкой, например:
   `TEST_PERSONAL_DATA_SNILS_112-233-445-95`.
2. Выполнить действие, которое на стенде контролируется DLP policy:
   копирование, перемещение, печать или другой включенный канал.
3. Дождаться обработки collector/server-side pipeline.

Ожидаемый результат:

- создается DLP-инцидент тестового типа;
- инцидент привязан к тестовому host/user;
- severity и policy/rule отображаются в карточке инцидента;
- инцидент не требует ручного редактирования SQLite или логов.

## 5. Просмотр case и evidence

Действия:

1. Открыть раздел `Инциденты ИБ`.
2. Найти созданный тестовый инцидент.
3. Открыть case detail.
4. Проверить evidence: screenshot, metadata, checksum или ссылку на артефакт,
   если evidence collection включен на стенде.
5. Отметить инцидент как просмотренный тестовым оператором.

Ожидаемый результат:

- case открывается из web UI;
- evidence доступно только через портал/API, а не через произвольный raw path;
- просмотр evidence фиксируется в audit trail или журнале case;
- checksum/metadata отображаются без раскрытия локальных приватных путей.

## 6. Экспорт отчета

Действия:

1. Открыть отчет по DLP/инцидентам или worktime management report.
2. Выбрать тестовый период, включающий созданный инцидент.
3. Экспортировать отчет в доступном формате стенда: HTML, CSV, JSON или PDF.

Ожидаемый результат:

- отчет формируется без ошибки;
- тестовый инцидент присутствует в отчете;
- отчет содержит дату, host/user, policy/rule, статус case и ссылку/идентификатор
  evidence;
- экспорт не содержит секретов, приватных токенов и внутренних путей оператора.

## 7. Завершение теста

Действия:

1. Пометить тестовый case как `closed`, `resolved` или аналогичный статус,
   если workflow стенда это поддерживает.
2. Повторно открыть список инцидентов и убедиться, что статус изменился.
3. Сохранить диагностический минимум:

```bash
detmir-check --json > expert-detmir-check.json
detmir-status --json > expert-detmir-status.json
```

Ожидаемый результат:

- статус case обновлен;
- повторный `detmir-check` не показывает новых критичных ошибок;
- эксперт может приложить JSON-выводы и экспортированный отчет к протоколу
  проверки.

## Критерий прохождения

Сценарий считается пройденным, если эксперт смог:

- войти в web-интерфейс;
- увидеть состояние контура;
- получить тестовый endpoint/DLP signal;
- открыть DLP case;
- просмотреть evidence;
- экспортировать отчет;
- закрыть или обработать тестовый инцидент без ручного вмешательства в БД.