Deal/.superpowers/sdd/channel-discovery/task-10-report.md

Task 10 — Отчёт: ТЗ, сборка и health-проверка

Статус

Выполнено. ТЗ дополнено разделом 4.9; docker-образ собран и контейнер перезапущен; фронтенд собран; py_compile всех файлов Discovery — OK; health/settings проверены по HTTP (200). Живой E2E с кандидатами/вступлениями не выполнялся (нужен реальный Telegram-аккаунт) — ручные шаги перенесены в «Осталось для ручной проверки».

Файлы

• Изменён: ТЗ.md — добавлен подраздел ### **4.9. Поиск и подключение каналов (Discovery)** (11 пунктов) между 4.8 и «5. Спецификация пайплайна обработки данных».

Что сделано

Step 1: Раздел ТЗ (4.9)

Структура файла: функциональные требования — секция 4.x (4.1–4.8), поэтому Discovery добавлен подразделом 4.9 (перед «5. Спецификация пайплайна»), в стиле остальных разделов (### **4.N. …** + маркированный список > *). Покрыто по спеке:

• Подвкладка «Поиск» на экране «Каналы»; задача поиска: описание цели → генерация поисковых ключей ИИ (редактируются до старта) → каскад фильтров по нарастающей стоимости (поиск/дедупликация → «мы не состоим» → число участников → язык → оценка содержимого).
• Глобальное правило «мы не состоим» — безусловное, для всех задач и всех этапов (поиск → оценка → вступление), повторная проверка перед join'ом.
• Метки: «закрытая группа/канал», «форум», «не прочитано», «участники не подтверждены», «язык не подтверждён», «мало сообщений», «есть проходные темы»; «не подтверждено» = сигнал человеку, не пропуск.
• Оценка содержимого с профилем задачи (без карточек/обучения ML); каналы/открытые группы — выборка до sampleSize, доля ≥ порога; открытая группа без чтения — на рассмотрение с меткой.
• Оценка по темам (форумы): тема «подходит X из N», группа подходит при ≥1 проходной теме, превью тем; ≥3 содержательных сообщений для оценки, иначе метка «мало сообщений»; закрытые группы — сразу на рассмотрение с меткой.
• Review/join/reject + чёрный список: «Вступить и мониторить» (monitor=1 + догон ~10 сообщений), «Отклонить» → чёрный список (исключение во всех задачах, снимается вручную), закрытые группы — ссылка t.me/<username> + авто-замечание при синхронизации.
• План задач и правило создания: план 1–50; сумма планов активных задач (не done/failed) ≤ суточного лимита (по умолчанию 50); у активной задачи план не увеличить сверх свободного бюджета.
• Авто-вступление и квоты: autoJoin на задачу; случайная пауза 50–70 с, по одному действию; лимит 50 авто-вступлений/сутки общий на все задачи; ручные — без квот; задача «выполнена» по плану, упор в бюджет — продолжение на следующий день.
• Анти-бан (BanGuard): мягкие паузы поиска/чтения, FloodWaitError → пауза + остановка авто-вступлений до следующего дня, общий «стоп-кран»; лимит/интервалы — настройки UI.

Step 2: Сборка и рестарт

• docker compose build app && docker compose up -d app — образ telbase-app собран, контейнер leadradar пересоздан и поднят; leadradar-ml/leadradar-minio — running.
• cd frontend && npm run build — без ошибок.
• python -m py_compile … (все файлы брифa) — без ошибок.

Вывод проверок

1. docker compose build app && docker compose up -d app → image built, контейнер Started; лог старта чистый (startup complete, без traceback).
2. cd /c/telbase/frontend && npm run build → ✓ built in 1.35s, 42 modules transformed, ошибок нет (сборка в Dockerfile — та же: 42 modules).
3. python -m py_compile backend/app/services/discovery.py discovery_eval.py discovery_worker.py ban_guard.py telegram.py backend/app/routers/discovery_routes.py settings_routes.py backend/app/main.py → OK.
4. GET /api/health → 200.
5. POST /api/auth/login (admin/admin) → 200; GET /api/settings → 200, discovery-ключи присутствуют: discJoinLimit: 50, discJoinDelayMin: 50, discJoinDelayMax: 70 (int-группа _PUBLIC_INT), discPaused: false (bool, отдаётся из _PUBLIC_BOOL); дополнительно discEvalSample: 10, discEvalThreshold: 40.
6. Smoke API: GET /api/discovery/tasks → 200 {"items":[]}, GET /api/discovery/blacklist → 200 {"items":[]} — роутер Discovery включён, БД-таблицы созданы.

Осталось для ручной проверки (E2E из брифа Step 3 — нужен подключённый Telegram-аккаунт)

1. «Каналы → Поиск» → создать задачу (описание, план 3, авто-вступление выкл) → «Сгенерировать ключи» → запустить.
2. Дождаться кандидатов; убедиться, что текущие подписки и отклонённые не появляются (правило «мы не состоим» + чёрный список).
3. Открыть кандидата: метки, участники, fit «X из N», темы форума.
4. «Вступить и мониторить» → источник в «Каналах» (monitor on) и начинает давать карточки.
5. «Отклонить» → источник в чёрном списке; повторно не находится.
6. Включить авто-вступление: проверить паузы (≥50 с) и расход суточного лимита (50).

Concerns

1. ТЗ-раздел написан кратко по спеке — детальные значения (таблицы полей задачи/БД, схемы API) сознательно не дублируются: в ТЗ это функциональный обзор, а точные контракты зафиксированы в дизайн-доке (ссылки на параметры discJoinLimit, sampleSize, autoJoin и т.п. даны).
2. «На рассмотрение»/вступление/чёрный список проверены только на уровне API-контракта (пустые списки 200) и логов запуска — поведение с живым Telegram-аккаунтом (поиск реально возвращает кандидатов, join проходит) остаётся за ручной проверкой пользователя.
3. discPaused — рантайм-настройка без дефолта в DEFAULT_SETTINGS; в GET /api/settings присутствует как false (bool), что подтверждено.
4. progress.md не трогался.