ss-tools/init_task.md

Это абсолютно логичный следующий шаг. Переход от Pull-модели (пользователь сам заходит в ss-tools посмотреть, не сломалось ли чего) к Push-модели (система сама бьет тревогу) — это стандарт для любого Enterprise инструмента.

Более того, раз вы уже внедрили профили пользователей и привязку аккаунтов Superset (как мы обсуждали в предыдущем шаге), у вас открывается возможность делать "Умный роутинг" (Smart Routing) уведомлений.

Вот как лучше всего спроектировать эту систему (UI, логика и форматы отчетов).

---

1. Умный роутинг (Киллер-фича благодаря профилям)

Вам не обязательно заставлять пользователей вручную вбивать email-ы для каждого дашборда. В Superset у каждого дашборда есть owners (владельцы).

Логика:

1. LLM-проверка дашборда завершается со статусом FAIL.
2. Бэкенд ss-tools смотрит: кто owners у этого дашборда в Superset? (например, admin и ivan.ivanov).
3. Бэкенд ищет этих пользователей в базе профилей ss-tools.
4. Если у ivan.ivanov в профиле ss-tools прописан Email или Telegram ID, система автоматически отправляет ему персональное уведомление: "Привет! Твой дашборд упал".

---

2. Как встроить это в UI (Настройки)

Разделите настройки на Глобальные провайдеры (для админов) и Правила отправки (для пользователей/задач).

А. Настройки интеграций (Global Settings -> Notifications)

Здесь администратор системы один раз настраивает доступы.

• Email (SMTP): Хост, Порт, Логин, Пароль, От кого (noreply@ss-tools.com).
• Корпоративный мессенджер: Webhook URL или Bot Token.
• Telegram: Bot Token.

Б. Настройка правил в "Политике проверки" (Validation Policy)

Когда пользователь настраивает расписание проверок (о котором мы говорили ранее), добавьте секцию "Уведомления".

[ Настройка LLM-проверки: Nightly Prod Check ]

... (выбор дашбордов и расписания) ...

🔔 Уведомления об инцидентах:
Отправлять при статусе:[ Только FAIL ⌄ ] (Опции: FAIL, FAIL + WARN, Всегда)

Куда отправлять:
[x] Автоматически Владельцам (Owners) дашборда (Email / Мессенджер из их профиля)
[x] В общий канал / группу:
    + Добавить канал
      [ Slack ⌄ ] -> Канал: [ #bi-alerts ]
      [ Email ⌄ ] -> Адрес:[ data-team@company.com ]

---

3. Дизайн самих уведомлений (Payload)

Очень важно, чтобы уведомление не было простыней логов, иначе его начнут игнорировать (Alert Fatigue).

✉️ Формат Email-письма (Богатый формат)

Письмо должно содержать всё необходимое, чтобы понять проблему без перехода в систему.

• Тема: 🔴 [ss-tools] Ошибка валидации: Sales Executive Dashboard
• Тело (HTML):
  • Заголовок: 🔴 FAIL: Sales Executive Dashboard (Окружение: PROD)
  • Краткий вердикт LLM: "Сломан чарт Revenue YTD. Ошибка базы данных: колонка profit не найдена."
  • Картинка: Вшитый скриншот дашборда с обведенной ошибкой (как он генерируется в вашей системе).
  • Кнопка: [ Открыть полный отчет в ss-tools ] (Deep link прямо на страницу с логами).

💬 Формат для Мессенджеров (Slack / Telegram)

В мессенджере картинки и длинные тексты читаются хуже. Формат должен быть сверх-компактным.

Сообщение от бота:

🚨 Dashboard Validation Failed Dashboard: Sales Executive Env: ss-prod | Time: 03:15 AM

🤖 LLM Summary: Обнаружена SQL-ошибка в чарте "Revenue". Данные не отображаются.

🔗 [View in ss-tools] 📊 [Open in Superset]

(Для Slack/Telegram можно прикрепить скриншот вторым сообщением или вложением, если API позволяет, но текст должен быть первичным).

---

4. Архитектура Бэкенда (Как это реализовать в FastAPI)

Чтобы код не превратился в спагетти, используйте паттерн "Издатель-Подписчик" (Pub/Sub) или абстрактную фабрику уведомлений.

1. Создайте базовый класс NotificationProvider:

   class NotificationProvider(ABC):
       @abstractmethod
       async def send(self, report: ValidationResult, recipient: str):
           pass
   

2. Реализуйте провайдеры: SmtpEmailProvider, SlackWebhookProvider, TelegramBotProvider.
3. Слой NotificationService: В конце выполнения DashboardValidationPlugin.execute(), плагин вызывает:

   await notification_service.dispatch_report(validation_result)
   

4. Служба NotificationService смотрит в БД настройки расписания и профили владельцев, решает, кому отправлять, и вызывает нужные провайдеры.
5. Фоновые задачи: Сама отправка почты/сообщений не должна тормозить основной поток задачи. Оберните вызов в BackgroundTasks FastAPI или отправляйте через Celery/Redis Queue, чтобы таска завершилась мгновенно, а письмо ушло асинхронно.

Итог по UX:

Пользователь заходит в свой профиль -> вводит свой Telegram ID -> ставит галочку "Уведомлять меня о моих упавших дашбордах". Всё! Дальше система сама берет на себя всю рутину. Если ночью дашборд, где он Owner, упал — он утром получает сообщение в телегу со скриншотом. Это "Wow-эффект" для конечного пользователя.