# Анализ разрывов готовности пилота 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 пакета внутренние формулировки про ``, 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, проверить наличие кандидата на расследование, открыть пакет расследования и заранее подготовить итоговый отчет.