Инфраструктура и тех-стек · спецификация и роадмап · быстрая обработка ситуативов · админ-таксономия событий.

Краткое резюме

Платформа из двух бизнесово раздельных продуктов, связанных глубокой интеграцией: Events («По душе» — офлайн-события) и Dating («По любви» — знакомства, существующее приложение plbvi.ru). Архитектура — 2 продуктовых бэкенда (events-backend, dating-backend; у каждого своя БД и домен, разводятся независимо) + общий слой платформенных сервисов, главный из которых — Identity/SSO (единый user_id). Это позволяет легко «развести» продукты потом, но при этом делать cross-app-интеграцию (статус «открыт для знакомств», переход между приложениями, «4 из 20 на событии открыты и подходят»).

Над бэками — 4 клиента (events/dating × mobile/web) и 1 общая админка-агрегатор. Дорогую инфраструктуру и регулируемое (identity/verification, notifications, media, analytics, moderation, payment-gateway) выносим в общие сервисы; доменную логику и данные держим в каждом продукте раздельно.

Документ покрывает: - §1 Инфраструктура и стек — дейтинг уже в проде на Python (Django+FastAPI, k8s в Yandex Cloud); наследуем стек и инфру, events строим в том же стеке; данные в РФ-облаке (152-ФЗ). - §2 Спецификация и роадмап — 2 бэка + общие сервисы + integration layer; фазы по зависимостям (P0→P8). - §3 Ситуативы — быстрое реагирование на инциденты (удаление/блокировка, сбои платежей/интеграций, модерация) через событийную шину и единый журнал; формирование решений. - §4 Админ-таксономия — единый журнал внутренних событий (от регистрации до ошибок). - §5–§6 Качество и безопасность — NFR-цели, пентест, нагрузка, масштабирование.

Дейтинг «По любви» — существующий прод (Python: Django+FastAPI, клиент Flutter, k8s в Yandex Cloud). Его бэкенд и есть dating-backend: мы его принимаем и достраиваем (общий identity, net-new фичи), а не переписываем; интеграция с events — через уже работающую Kafka.

1. ИНФРАСТРУКТУРА И ТЕХНОЛОГИЧЕСКИЙ СТЕК

Важная вводная: дейтинг «По любви» уже работает в проде на зрелом стеке (Python + k8s в Yandex Cloud). Поэтому стек мы не выбираем с нуля — наследуем существующее и достраиваем недостающее. Events — net-new; решение принято: строим его в том же стеке (Python — Django+FastAPI), чтобы переиспользовать инфраструктуру, CI и identity.

1.1 Реальная архитектура «По любви» (как есть, из репозиториев)

Вывод: инфраструктура, шина (Kafka), хранилища, контракт-фёрст-пайплайн и DevOps-контур — уже есть и в РФ-облаке. Это меняет роадмап: первый шаг — не «строим инфру с нуля», а принимаем существующую (доступы, registry, CI, дампы БД).

1.2 Целевой стек — достраиваем поверх реальности

Для дейтинга стек наследуем. Для events-backend (net-new) решение принято — тот же стек (Python), чтобы переиспользовать инфру/CI/identity и не раскалывать команду. Отдельно — слои, которых сейчас нет и которые надо докупить/построить.

1.3 Принципы

1. РФ-локализация по умолчанию (152-ФЗ). ПДн, фото/голос (биометрия, отдельные согласия) — физически в РФ-облаке. Уже соблюдается: всё в Yandex Cloud.
2. Наследуем стек, не переписываем. Единый Python-периметр (Django+FastAPI) + контракт-фёрст (swagger→surfgen) + Flutter — как у существующего дейтинга; events в том же стеке. Переписывать рабочий прод на другой язык — риск без выгоды.
3. Переиспользуем существующую инфру. Kafka, PostgreSQL, Redis, S3, k8s/ArgoCD/Vault — уже в проде. Шина Kafka есть сейчас — это не «фаза V2».
4. BUY для AI/инфраструктуры — BUILD для доменной логики и ПДн. Покупаем CV/text-модерацию, SpeechKit, LLM, ЕСИА/ФССП, ЮKassa; пишем сами identity, скоринг-оркестрацию, репутацию, эскроу, events-домен, integration layer.
5. Net-new строим точечно — только то, чего в проде ещё нет (см. §1.2): events-домен, общий identity, GPS-радар, голосовой онбординг, скоринг, ЮKassa-эскроу, единая админка, AI-модерация.

1.4 Что покупаем (BUY) vs пишем сами (BUILD)

Уже есть — наследуем: Python-бэкенд (Django/FastAPI/Dramatiq), managed PG/Redis/Kafka/S3, k8s/ArgoCD/Helm/Vault/Terraform, swagger→surfgen, Flutter-клиент, IAP-платежи, Firebase/AppMetrica/AppsFlyer.

Покупаем (BUY) — net-new: CV/text-модерация (UGC для сторов), Yandex SpeechKit, LLM-API (обезличенный текст), ЕСИА/ФССП/KYC-провайдеры, ЮKassa + ФНС/НПД. Регулируемые внешние системы — пишем только обёртки/комплаенс вокруг.

Пишем сами (BUILD) — наш IP: общий identity/SSO (единый user_id на базе Django-auth), скоринг-оркестрация и тиры доверия, репутация, эскроу/сплит (events), events-домен (RSVP/waitlist/check-in/афиши), GPS-радар и голосовой онбординг (dating net-new), integration layer events↔dating, единая админка.

2. СПЕЦИФИКАЦИЯ + ТАЙМЛАЙН

2.1 Что строим (спецификация скоупа)

Два бизнесово раздельных продукта на общей платформе: Events («По душе» — офлайн-события) и Dating («По любви» — знакомства). У каждого — свой бэкенд со своей БД и доменом (независимый деплой, при необходимости разводятся), сверху — тонкий слой общих платформенных сервисов и integration layer для cross-app-связки. Над всем — 4 клиента и 1 общая админка-агрегатор.

Топология:

Что шарим vs держим в продукте. Логика: общими делаем чистую инфраструктуру, регулируемое (152-ФЗ) и кросс-продуктовое; доменную логику и данные держим раздельно, чтобы продукты дёшево «развести».

Интеграция events↔dating (сценарий)

Продукты раздельные, но внутри каждого — интеграция другого. Ключевой механизм: в Events пользователь ставит статус «открыт для знакомств», и это разворачивает расширенный функционал через cross-API к dating-backend:

• Подсветка статуса в events-профиле; на событии — «4 из 20 участников открыты для знакомств и подходят под твои критерии» (events-backend → dating-backend: кто из этих user_id открыт + matches).
• Deep-link в «По любви» за полной анкетой / доп.фото / видеокружочками.
• Фильтры «показывать события/людей с таким же статусом»; рекомендации людей и событий учитывают флаг.
• Обратно: dating-backend → events-backend — «встречал вживую» / общие посещённые события как сигнал для дейтинга.

Флаг «открыт для знакомств» и базовый кросс-профиль живут на shared identity (читают оба продукта); полная анкета — в dating-backend.

Как это ложится на реальный API «По любви»

Связь events↔dating — через общий identity + Kafka + swagger/REST (тот же контракт-фёрст, что в дейтинге). Сценарии выше опираются на уже существующие домены API «По любви»:

Net-new под интеграцию (поверх существующего API): флаг «открытости» на identity, фильтр matching «по событию/участникам», пометка «met-IRL». Всё остальное — matching / likes / chat / community / profile / survey — переиспользуем как есть.

Продукт Events (events-backend). Платформа офлайн-событий: создание события, RSVP (мгновенно / по одобрению, waitlist), карта+список как главный экран, pre-event чат, geo-fenced check-in, post-event review, парсинг внешних афиш (Timepad/KudaGo) для cold-start.

• Создание события L1/L2, recurring-серии; RSVP-движок (capacity, waitlist, одобрения).
• Геопоиск (PostGIS), карта/список, geo-fenced check-in.
• Pre-event чат, post-event review, репутация явки; парсинг афиш (cold-start).

Продукт Dating (dating-backend). «По любви» (plbvi.ru) — существующее приложение знакомств для серьёзных отношений и семьи («знакомства для души»). Его бэкенд (Django+FastAPI) мы принимаем как dating-backend и достраиваем: подключаем к общему user_id, добавляем net-new фичи. Это не переписывание — перенос данных (дампы из S3 на целевой контур) + аккуратный strangler там, где выносим identity.

Текущие фичи «По любви» (переносим как есть):

• Селфи-верификация + строгая модерация — «только реальные люди», без фейков.
• «Открывашки» — ответы на вопросы-открытки для самопрезентации.
• «Видеокружочки» — короткие видео о себе.
• Лимит 8 лайков/день; «Записочки» — прямое сообщение тому, кто понравился.
• Reels от психологов об отношениях; тематические Сообщества.

Что добавляем поверх (новое):

• GPS-пересечения профилей (фоновый BLE-радар на iOS нереализуем — исключён).
• События в свайп-ленте + сигнал «пошёл бы / не интересно» (каталог из events-backend по API).
• Голосовой онбординг — RU-каскад (Yandex SpeechKit + LLM на обезличенном тексте) + текстовый фолбэк.
• Комплаентный скоринг — ЕСИА + ФССП-самопроверка + self-upload справок (без госбаз судимостей, без скрейпинга соцсетей).
• AI-модерация фото и чата (обязательна для сторов).

2.2 Фазовый роадмап

Роадмап исходит из того, что дейтинг уже в проде: первые фазы — не «строим с нуля», а принимаем существующую систему и инфру, затем достраиваем net-new и строим events. Фазы — по зависимостям; клиент и интеграция идут внахлёст.

Параллелизм. P5/P6 идут внахлёст с P4, compliance (P8) тянется процессно с P0 — реальный календарь короче суммы длительностей. Ключевое отличие от greenfield: P1–P3 опираются на готовый прод дейтинга, а не на стройку ядра с нуля. Внешние блокеры (KYC ЮKassa, ревью сторов, статус ИС в ЕСИА, доступ к дампам/legacy) ресурсами не сжимаются.

3. Обработка ситуативов: быстрое реагирование и решения

Ситуатив — любое значимое событие или инцидент в системе: от удаления/блокировки аккаунта до сбоя платежа, застрявших в эскроу денег, жалобы или падения внешней интеграции. Цель — не расписать один сценарий до винтика, а иметь единый механизм: быстро поймать → быстро отработать → сформировать решение (авто или человеком).

3.1 Единый механизм

• Каждый продукт/сервис публикует событие в шину (Kafka, уже в проде) с общим correlation_id.
• Заинтересованные сервисы реагируют идемпотентно (отмена, возврат, уведомление, скрытие, отзыв доступа).
• Всё стекается в единый журнал админки (§4) с темой / severity / тегами — оператор видит ситуатив и формирует решение в одном экране; критичное (critical) уходит в алерт.
• Принцип UX: пользователю никогда не показываем 500/битый экран — ситуатив деградирует в понятное состояние.

3.2 Каталог типовых ситуативов

Любой ситуатив — это та же связка «событие → идемпотентная реакция → запись в журнал → решение». Новый добавляется как новая тема/правило, а не как отдельная подсистема.

3.3 Пример: удаление и блокировка аккаунта

Самый «сквозной» ситуатив — показывает механику целиком. Identity-сервис (источник истины аккаунта) публикует account.blocked / account.deleted; оба продуктовых бэка и общие сервисы реагируют идемпотентно:

• identity — мгновенный отзыв сессий/токенов; media — удаление фото/видео/биометрии; events/dating — скрытие из ленты/поиска, отмена будущих RSVP, разрыв матчей; payments — заморозка выплат, сага по эскроу; analytics — анонимизация (агрегаты сохраняем); admin/audit — след сохраняем всегда.
• Режимы: блокировка (временно, другим видно «аккаунт недоступен») vs удаление (soft-delete с окном отмены ~30 дней → purge) vs анонимизация.
• Тяжёлый кейс: деньги в эскроу при бане организатора с предстоящим платным событием — сага: вернуть гостям / переназначить хост, не «потеряв» деньги.
• Ретеншн: платёжные/ФНС/аудит-данные храним по закону даже после удаления (152-ФЗ: право на удаление vs обязательное хранение).

Все шаги каскада — обычные события в том же журнале (§4), развёрнутые по correlation_id: видно, что отработало штатно.

4. АДМИНКА: таксономия внутренних событий (теги/темы) — от новой регистрации до ошибок

4.0 Назначение и принцип

Команда оперирует двумя продуктами на общей платформе. Если каждый модуль (общие сервисы, events-backend, dating-backend) ведёт свой журнал, оператор поддержки, модератор, антифрод и дежурный инженер смотрят в разные места и не видят причинно-следственных связей. Поэтому в админке заводится единый фид внутренних системных событий — один поток, в котором появляется всё: регистрация, верификация, модерация, платежи, события/дейтинг, гео, рост, комплаенс и ошибки. Каждое событие классифицируется по теме (бизнес-домен) и severity (важность), помечается тегами (пересекающиеся срезы) и связывается с цепочкой через correlation_id.

Бизнес-смысл для CPO: - Один экран на всю систему → поддержка/модерация/антифрод не переключаются между инструментами, время реакции на инцидент падает. - Тема ≠ severity ≠ тег — три независимых оси фильтрации. Тема отвечает на «что за домен», severity — «насколько срочно», тег — «по какому срезу искать» (например biometric, pii, fraud, money). Это даёт точные дашборды и алерты без раздувания числа типов. - RBAC встроен в таксономию: payload с ПДн/биометрией виден не всем (152-ФЗ), а сам факт доступа к чувствительному событию логируется как событие (compliance.audit.access). - Переиспользование, а не новый код: фид строится поверх уже работающей шины (Kafka) и логов/аналитики — отдельная подсистема логирования не нужна.

4.1 Каталог тем (групп) событий

Severity — фиксированная шкала из 4 уровней: info (норма, для аудита/аналитики), warning (требует внимания, не блокирует), error (сбой операции/нарушение правила), critical (угроза деньгам/данным/доступности — порождает алерт).

RBAC-роли: Support-L1 (Support Specialist), Moderator (Support 1-я линия модерации/Community Manager), Antifraud, Finance (payment-focused BE/финоператор), Compliance/DPO (ответственный за ПДн, оператор РКН), Engineer/On-call (Backend/DevOps), Admin (PM/Founder — полный доступ). Принцип least-privilege: чувствительный payload (биометрия, ПДн, платёжные реквизиты) маскируется для ролей, которым он не нужен.

Темы ↦ реальные сервисы-источники. - Auth, Profile, Matching, Likes, Survey, Community, Referral, Cities → django-main-app (Django/DRF; ранжирование подбора — scikit-learn). - Chat → fastapi-chat-app (FastAPI/WebSocket + Kafka). Verification (селфи) → fastapi-verification-app. - Payments: dating — нативные IAP/подписки (payment/subscription); events — ЮKassa (net-new). - Events-домен, GPS-радар, голосовой онбординг, ЕСИА/ФССП-скоринг, AI-модерация — net-new сервисы. - Фоновое (нотификации, обработка видео, ретеншн) → Dramatiq-воркеры.

Auth / Registration

Profile / Media

Moderation

Payments

Events (events-backend)

Dating (dating-backend)

Geo

Growth / Referrals

Compliance

System / Errors

Security / Antifraud

4.2 Модель данных и источник

Единая структура события (event / audit-log)

{
  "id":             "evt_01J9...",        // ULID, монотонный, сортируемый по времени
  "ts":             "2026-06-25T10:31:02.581Z",
  "theme":          "Payments",            // тема из каталога §4.1 (enum)
  "type":           "payment.fns.receipt.failed", // <module>.<entity>.<action>
  "severity":       "critical",            // info | warning | error | critical
  "actor": {                               // кто инициировал
    "kind": "user|operator|system|integration",
    "id":   "usr_4821", "role": null
  },
  "target": {                              // на кого/что направлено
    "kind": "user|event|payment|profile|...",
    "id":   "pay_99213"
  },
  "tags":           ["payments","money","integration","fns","compliance"],
  "payload":        { /* доменные поля; ПДн/биометрия — отдельный класс, маскируется по RBAC */ },
  "correlation_id": "corr_5f1c...",        // сквозной id цепочки бизнес-операции
  "source":         "dating.fastapi-chat",   // сервис: dating.django-main | dating.fastapi-chat | dating.fastapi-verification | events-backend | shared.identity | dramatiq
  "pii_class":      "biometric|pii|none"   // класс чувствительности → правило маскирования и хранения
}

Соглашения, чтобы таксономия оставалась управляемой: - type = <module>.<entity>.<action> — иерархичен, новые типы добавляются без миграций, фильтр по префиксу (payment.*) работает из коробки. - theme — закрытый enum, привязан к модулю-владельцу. Темы стабильны, типы растут. - tags[] — открытый, но из словаря (pii, biometric, money, fraud, audit, cascade, integration, …). Один тег пересекает темы: money ловит и Payments, и Growth-фрод; pii — и Auth, и Compliance. Это даёт срезы, недоступные через тему. - pii_class управляет двумя вещами: маскированием payload в UI (RBAC) и политикой хранения (см. ниже).

Источники и хранение

Принцип: витрина — для объёма и аналитики, durable-стор — для доказуемости. Критичные события пишутся в оба (dual-write через шину). Хранение по классам: none/pii info-события — короткий TTL в аналитической витрине; audit/compliance/money — длительное durable-хранение по требованиям регуляторов; биометрические payload не дублируются в фид — событие хранит только факт и ссылку, сами биоданные лежат в защищённом хранилище с отдельным согласием.

correlation_id присваивается в точке входа (регистрация, открытие платежа, создание события) и протягивается через шину по всей цепочке. Именно он связывает «рега → верификация → платёж → ошибка» в один трейс и соединяет фид с логами/метриками в Grafana/Loki (уже в инфре; distributed tracing OTel/Tempo — по мере внедрения).

4.3 UX админки

Лента (основной экран). Реверс-хронологический поток событий. Каждая строка: время · цветной бейдж severity · тема · type · actor → target · теги-чипы · кнопка drill-down. Цветовой код severity: info — нейтральный, warning — янтарный, error — красный, critical — красный с пульсацией + значок алерта.

Фильтры (комбинируются, сохраняются в URL).

Drill-down в событие. Полная карточка: вся структура §4.2, развёрнутый payload (с маскированием по RBAC), кнопки действий из §4.1 (контекстно по теме), ссылки на профиль/транзакцию/событие и переход в Grafana/Loki по correlation_id.

Drill-down в цепочку (по correlation_id). Таймлайн-вид: все события одной бизнес-операции в хронологии, с переходами между темами и подсветкой, где цепочка «сломалась» (первый error/critical). Это ключевой инструмент разбора инцидентов — видно весь путь от регистрации до сбоя.

Сохранённые фильтры (saved views). Преднастроенные ленты под роли, чтобы не собирать фильтр заново: - Дежурный инженер: severity ≥ error, темы System/Errors + Payments-integration. - Антифрод: тег fraud/antifraud/bot + Security/Antifraud + Geo-fake. - DPO/Compliance: тег pii/consent/dsr/audit + темы Compliance/Moderation-каскад. - Финансы: тема Payments + тег money. - Модерация: Moderation + Profile-autoflag + Dating-report.

Алерты на critical. Любое severity=critical (фискализация ФНС, деградация сервиса, подозрение на утечку, чарджбек-шторм) → мгновенный алерт в Telegram (дежурный чат) и на почту ответственной роли, с дедупликацией и группировкой, чтобы один инцидент не породил сотню сообщений. Алерты конфигурируются по комбинации тема+severity+тег.

Дашборды по темам. Поверх аналитической витрины: динамика событий по темам, доля error/critical, воронка Auth/Registration (рега → селфи → документ → ЕСИА), здоровье платежей (success-rate ЮKassa, фейлы ФНС), очередь модерации, лаги консьюмеров шины. Дашборды и лента используют одни и те же оси (тема/severity/тег) — то, что видно агрегатом, разворачивается в конкретные события одним кликом.

4.4 Связь с разделом 3 (каскад блокировки/удаления)

События жизненного цикла аккаунта из раздела 3 — не отдельный механизм, а часть этого же фида. Когда срабатывает account.blocked или account.deleted и запускается каскад (отмена будущих RSVP/событий, разрыв матчей, остановка выплат, удаление медиа, отзыв согласий), каждый шаг каскада публикуется в шину как обычное событие с общим correlation_id блокировки/удаления:

В админке оператор открывает событие account.deleted, разворачивает по correlation_id — и видит весь каскад: что именно было удалено/отменено, в каком порядке, без ошибок ли. Для DPO это готовое доказательство исполнения требования по удалению ПДн (152-ФЗ): единый журнал = единый источник правды, не нужно собирать подтверждения из разных модулей.

4.5 Сквозной пример: жизненный цикл в ленте

Один пользователь, одна цепочка correlation_id=corr_5f1c. Как это выглядит в фиде (новый → старый порядок показан сверху вниз по времени):

Как это читается командой: - Поддержка фильтрует по target.id=usr_4821 и видит всю историю человека в одной ленте — от реги до жалобы. - DPO по тегу pii/consent и шагам 2–4 доказывает, что биометрия собрана с согласием (152-ФЗ). - Модератор по теме Moderation (шаги 6–7) разбирает жалобу с полным контекстом. - Финансы/дежурный получают алерт по шагу 8 (critical), открывают цепочку по corr_5f1c и сразу видят, что упала именно фискализация уже успешного платежа — ретраят чек, не трогая сам платёж. - Всё это — одна цепочка corr_5f1c, развёрнутая в drill-down как таймлайн: видно, что система отработала штатно, а сбой — только на последней внешней интеграции.

Источник истины по реальному стеку дейтинга — репозитории nikea-backend, nikea-swagger, nikea-backend-infra (Django/FastAPI, swagger→surfgen, k8s/ArgoCD/Vault).

5. Нефункциональные требования и качество (NFR)

5.1 Целевые показатели качества

Crash-free и latency — релиз-гейты: сборка не уходит в прод/стор, если показатели хуже порога.

5.2 Покрытие устройств и версий (цель ≥ 80%)

• iOS: три последних мажорных версии (ориентир iOS 16–18), минимум iOS 15 (deployment target в проекте 12–15) → ~95%+ активных устройств.
• Android: minSdk 28 (Android 9.0) — как в приложении сейчас (compileSdk 36 / targetSdk 35) → ≥ 80% активных устройств РФ. Пуш сейчас — FCM + AppMetrica; RuStore (дистрибуция) и Huawei/HMS — отдельно учесть/добавить (в коде их пока нет), иначе теряем долю РФ-рынка.
• Матрица версий фиксируется и пересматривается ежеквартально по статистике установок.

5.3 Клиент: Flutter (как сейчас) → нативные модули точечно

• База: Flutter — как у существующего «По любви»; один стек на обе апки (events/dating) и переиспользование наработок дейтинга; перф-чувствительные куски (карты/гео, камера/верификация) — точечно нативными модулями (platform channels).
• Триггер перехода на натив: после релиза stable MVP и подтверждения PMF, если упираемся в производительность/нативные возможности (плавность свайп-ленты, карта/гео, анимации, фоновые сценарии).
• Подход — постепенный (brownfield), не big-bang: сначала самые перф-чувствительные экраны (лента, карта, чат), при необходимости — полная нативная переписка одной из апок. Снижает риск против «переписать всё сразу».
• Только по метрикам: полная нативная переписка — заметные доп.затраты и время → делаем лишь при доказанной необходимости по §5.1, а не по умолчанию.

6. Безопасность и DevOps-гейты

6.1 Тестирование безопасности

• Пентест: внешний — обязательный gate перед публичным релизом, далее раз в 6–12 мес и после крупных изменений. Охват: мобайл (OWASP MASVS), API, инфра, флоу ПДн/платежей.
• В CI постоянно: SAST (код), SCA (зависимости/CVE), DAST (по стейджу), секрет-сканер — добавляем в существующий пайплайн (сейчас CI — Jenkins PR/TAG-джобы + ruff-линт).
• Bug-bounty — опционально после релиза.

6.2 Нагрузочное и стресс-тестирование

• Нагрузочные тесты (k6 / Locust / Gatling) — net-new, добавляем (сейчас в проде их нет): перед релизом и пиками, целевой RPS с запасом, проверка автоскейла, soak-тесты на утечки/деградацию.
• Часть CI/CD-гейтов перед прод-деплоем; результаты питают capacity planning.

6.3 Динамическое (полуавто) масштабирование

• K8s HPA (CPU/RPS/кастомные метрики) + Cluster Autoscaler (ноды). Managed-кластер в Yandex есть, но cluster-autoscaler сейчас выключен, а HPA — настроить. «Полуавто» = включаем автоскейл по метрикам + ручной контроль порогов и capacity planning по §6.2.

6.4 ТГ-боты (верификация и аналитика/алерты)

• Бот верификации: быстрый low-friction канал подтверждения личности/ускоренной верификации (Telegram/MAX-bot link в онбординге), интеграция с identity/verification.
• Бот аналитики/алертов: дежурные алерты critical (§4), быстрые метрики/отчёты для команды.
• 152-ФЗ: в ботов не уходят ПДн — только id-ссылки, метрики, severity, correlation_id (согласовано с §4.3).

6.5 Предиктивные белые списки + «рубильник» сертификатов

Единый контур безопасности, оба аспекта:

• Антифрод-allowlist'ы (юзеры/устройства): предиктивные списки доверенных (поведение, репутация, верификация) — снижают трение для «хороших» и фокусируют антифрод/модерацию на рисковых; риск-скоринг устройств/аккаунтов отдаёт сигнал в moderation/growth.
• Инфра/доступы: IP-allowlist на админку и служебные эндпоинты; отзыв клиентских сертификатов / ключей / токенов API.
• Cert kill-switch (мобайл): certificate pinning (net-new в Flutter-клиенте) с удалённым отзывом/ротацией пина через remote-config (Firebase Remote Config — уже в приложении, §1) — при компрометации/плановой смене сертификата апки не «кирпичатся» и не ждут релиза в сторе. Закладываем remote pin-set + аварийный bypass.
• Все срабатывания — события темы Security в админ-фиде (§4); механика kill-switch — поверх Firebase Remote Config (§1).