# Анализ разрывов готовности пилота AWatch-rus

Дата аудита: 2026-06-06.

Аудируемый срез: `origin/main`,
`9c57d6d2ce7eae1b133c937f037b24933f5797fe`.

Цель: объективно определить готовность AWatch-rus к контролируемой пилотной
эксплуатации и демонстрации руководителю, ИБ и эксплуатации.

Ограничения аудита: код, архитектура, сущности и интеграции не изменялись.
Сформирован только этот аудитный документ.

Не входило в аудит: pfSense, Telegram, Grafana, InfluxDB.

## Что готово

- Архитектура пилота выстроена как понятная цепочка:
  `агент -> телеметрия -> аналитика -> риск -> расследование -> отчет`.
- Rust workspace на текущем `origin/main` проходит обязательные проверки:

| Проверка | Результат |
| --- | --- |
| `cargo test --workspace` | Пройдено. |
| `cargo clippy --all-targets --all-features` | Пройдено. |
| `cargo build --release` | Пройдено. |
| `node scripts/detmir-portal-tabs-smoke.mjs` | Пройдено против рабочего портала через временный туннель; `security_events=available`. |

- Portal UX проходит smoke: вкладки `Обзор`, `Сотрудники`,
  `Подразделения`, `Риски`, `Расследования`, `Сетевой периметр`, `Отчеты`,
  `Настройки` открываются без ошибок консоли и HTTP 4xx/5xx.
- Executive View готов к показу руководителю: главный вывод расположен первым,
  порядок управленческих блоков подтвержден smoke, англоязычные и лишние
  технические термины в проверяемом пользовательском слое не обнаружены.
- Security View готов к показу ИБ: есть кандидаты на проверку, расследования,
  аудит, материалы расследования и переход из риска в карточку расследования.
  Smoke подтвердил 3 кнопки перехода к расследованию.
- Operations View готов к показу эксплуатации: видны полнота и качество
  данных, состояние источников, режим событий безопасности и ошибки сбора.
- ClickHouse integration работает в пилотном контуре: `/api/health`
  возвращает `ok=true`, источник `security_events` активен, портал получает
  агрегированные события безопасности через ClickHouse.
- Сбор данных 1С и DLP зафиксирован как Rust-first runtime: `aw-1c-ingest-rust`
  и Windows telemetry/evidence sync работают с 15-минутным циклом; скриншоты
  1С не копируются, доказательные PNG остаются только для DLP-событий.
- Agent/Rust migration закрывает критичный runtime-риск: основной сбор
  worktime, browser/domain, URL/domain extraction, clipboard/USB/print
  incident semantics и DLP evidence path покрыты Rust-бинарниками и тестами.
- Документы `docs/PORTAL_RU.md` и `docs/SECURITY_EVENTS_CLICKHOUSE_RU.md`
  присутствуют и отражают текущую модель портала и ClickHouse-событий.
- Пилотные документы находятся в единой структуре `docs/`:
  `docs/CUSTOMER_PILOT_PACK_RU.md`, `docs/PILOT_READINESS_AUDIT_RU.md`,
  `docs/SALES_POSITIONING_RU.md`, `docs/DEMO_RUNBOOK_RU.md`.
- 10-минутный демонстрационный путь технически доступен: главный риск,
  подразделение, причина риска, кандидат, расследование, пакет расследования и
  итоговый управленческий вывод показываются в портале.

## Что критично исправить

Критичных блокеров в коде, сборке и smoke-проверке для контролируемого пилота
на текущем срезе не выявлено.

Критичные условия перед фактическим показом:

- Демо должно запускаться на контуре, где развернут именно commit
  `9c57d6d2ce7eae1b133c937f037b24933f5797fe` или более новый проверенный срез.
- Перед показом нужен короткий преддемо-прогон на той же сети и экране:
  открыть портал, дождаться `Данные готовы`, проверить кандидата, открыть
  расследование и сформировать отчет.
- Нельзя продавать текущий срез как промышленно завершенную платформу без
  оговорок по доступу, retention, backup, versioning и регламенту эксплуатации.

## Что желательно исправить

- Русифицировать заголовки customer-facing документов: текущие документы
  используют названия вроде `Customer Pilot Pack` и `Sales Positioning`, что
  слабее выглядит на показе руководителю и заказчику.
- Отдельно перед демо проверить экспорт в формате, который будет показан:
  текстовый отчет, печать или PDF.
- Добавить в регулярный smoke мобильный/визуальный прогон. Текущий
  `detmir-portal-tabs-smoke.mjs` хорошо проверяет функциональный путь, но не
  является полноценной визуальной regression-проверкой.
- Сформировать явную матрицу совместимости API: agent, portal, telemetry,
  ClickHouse security events и investigation state.
- Убрать из публичного customer-facing пакета внутренние формулировки про
  `<LOCAL_CARGO_TARGET_DIR>`, private contour и служебные runtime-детали.

## Что перенести после пилота

- Полное hardening локальных JSON/JSONL/state-хранилищ: atomic write,
  блокировки, retention, backup/restore и нагрузочные тесты больших файлов.
- Промышленный app-layer RBAC для портала. Сейчас ролевые представления есть в
  UX, но контроль доступа должен оставаться задачей защищенного контура или
  reverse proxy до отдельного product hardening.
- Полное удаление оставшихся PowerShell deploy/bootstrap/fallback-элементов.
  Для пилота важно отсутствие PowerShell как основного runtime-сборщика; полная
  зачистка deploy-истории не является блокером показа.
- Load/sizing-профиль под промышленную эксплуатацию: количество рабочих мест,
  объем событий, глубина хранения, требования к ClickHouse и файловому evidence.
- Формальные регламенты хранения и доступа к материалам расследований.
- CI-упаковку customer-facing документов с проверкой путей, ссылок и русских
  заголовков.

## Риски пилота

| Риск | Влияние | Оценка |
| --- | --- | --- |
| Контур демо не совпадает с проверенным commit | Возможны расхождения UI, API или данных | Критично контролировать перед показом |
| Документы или ссылки изменятся без проверки | Путает hand-off и приемку пакета | Контролировать markdown link-check перед передачей |
| Первый запуск портала без прогрева | Может выглядеть как зависшая загрузка | Управляемо преддемо-прогоном |
| В текущих данных исчезнут кандидаты на расследование | 10-минутный сценарий потеряет самый сильный пример | Проверять `/api/reports` перед демо |
| ClickHouse станет недоступен | Operations View покажет fallback/ошибку вместо полного ИБ-среза | Не блокер UI, но слабее для ИБ |
| Нет промышленного RBAC внутри приложения | Нельзя открывать портал вне защищенного контура | Для контролируемого пилота приемлемо |
| Остаточные PowerShell deploy/fallback артефакты | Могут вызвать вопросы эксплуатации о миграции | Объяснять как legacy/fallback, не runtime-core |
| Нет полной визуальной mobile regression-проверки в обязательном smoke | Возможны мелкие UX-дефекты на нестандартном экране | Проверить вручную перед показом с планшета/ноутбука |

Дополнительное наблюдение: один первичный запуск smoke через только что
созданный туннель один раз не дождался `READY` за 30 секунд. Повтор с тем же
30-секундным таймаутом прошел примерно за 8 секунд, `/portal/api/reports`
отвечал примерно за 0.4 секунды. Это не выглядит как продуктовый блокер, но
подтверждает необходимость преддемо-прогона.

## Итоговая оценка готовности

Статус: AWatch-rus готов к контролируемому демонстрационному пилоту на текущем
`origin/main`.

Оценка готовности: 88%.

Обоснование:

- Сборка, тесты, clippy, release build и portal smoke на проверенном срезе
  успешны.
- Executive/Security/Operations View закрывают основной сценарий для
  руководителя, ИБ и эксплуатации.
- Rust runtime migration убрал главный риск зависимости от PowerShell в
  рабочих сборщиках.
- ClickHouse-события безопасности доступны и отражаются в портале.
- Оставшиеся разрывы относятся в основном к вычитке документов, преддемо
  дисциплине, промышленному hardening и формальному управлению доступом.

Рекомендация: допустить к пилоту только как контролируемый демонстрационный
контур. Перед показом выполнить короткий smoke на рабочем URL, проверить
наличие кандидата на расследование, открыть пакет расследования и заранее
подготовить итоговый отчет.
