Обновления

Коротко

Рассылка пошла, и теперь весь процесс виден: кому ушло, какое письмо и, главное, кто ответил. Заинтересованные ответы подсвечиваем, чтобы реагировать сразу, пока контакт «тёплый».

Видно всю рассылку

По кнопке «📬 Рассылка» открывается отдельный экран. По каждому письму — компания, дело, тип письма (под стадию) и статус. Сразу видно, сколько ушло и по каким делам. Можно открыть и сам текст письма, которое получил адресат.

Ответы — сразу и с тоном

Как только приходит ответ, он попадает в общий список и помечается по тону — интерес, отказ или нейтрально. На заинтересованные реагируем быстро: чем раньше ответить, тем выше шанс на разговор.

Письма доходят до адресата

Часть адресов в базе оказалась нерабочей — компания сменила почту или домен закрыт. Теперь такие случаи ловим автоматически: если письмо не дошло, оно сразу уходит на запасной адрес той же компании, а заведомо мёртвые адреса отсеиваем ещё до отправки. Плюс там, где письмо шло на общий ящик info@, по возможности переключаем на адрес на домене самой компании — ближе к нужному человеку. Так стараемся, чтобы письмо реально доходило, а не терялось.

Коротко

По каждому делу теперь видно, когда ближайшее судебное заседание — дата, время и зал. Открываете карточку дела — и сразу видите, без захода в kad.

Где смотреть

В карточке дела появился блок «Судебные заседания». Сверху — ближайшая дата, ниже — история, если заседание уже переносили.

Дату берём прямо из карточки дела на kad и обновляем на каждом обходе. Если суд перенесёт заседание — новая дата подтянется сама, а прежняя останется в истории, чтобы было видно, как двигали.

Заполнили по всем делам

Заметили, что по части дел дата не показывалась, хотя в kad она есть. Поправили и прошлись по уже принятым делам — заполнили задним числом. Теперь дата стоит везде, где суд её назначил.

Коротко

Прошлись по вашим правкам к письмам и кое-что улучшили по возвратам. Всё для чтения — на схеме путь дела → письмо.

Что поправили в письмах

По вашим замечаниям:

• Подпись — везде «Иван Блинов, руководитель практики реструктуризации задолженности и банкротства», от ЮА «Правый Берег». Контакт — офисный телефон.
• Возврат — убрали из предложения госпошлину, оставили только депозит на вознаграждение управляющего.
• СРО — пишем по всем, не только по нашей: название СРО берём прямо из определения по конкретному делу.

Обездвижка — отдельное письмо под каждую причину

Вы отметили, что коллекция была неполной — был только «не внесён депозит». Теперь под каждое основание обездвижки свой текст:

• не уплачена госпошлина;
• не внесён депозит;
• недостатки по форме и документам;
• нет публикации уведомления о намерении на ЕФРСБ;
• не направлена копия заявления.

Логика предложения: если дело в деньгах (госпошлина/депозит) — «оплатим ровно это, а вы предлагаете нашего управляющего»; если в документах — берём сопровождение на себя и доводим заявление до принятия. Каждое письмо — отдельная карточка на схеме, открывается полный текст.

По возвратам — определяем настоящую причину

Раньше причину возврата мы ловили по набору типовых формулировок — и часто промахивались. Теперь система сама вычитывает причину прямо из определения суда по каждому делу.

Что это даёт:

• точнее письмо — называем заявителю реальную причину, по которой его заявление вернули;
• отсев лишнего — система отделяет дела, по которым писать не нужно: где заявитель сам отозвал заявление; где это вообще не возврат, а дело по ошибке попало в список (на самом деле его приняли); где речь про включение в реестр, а не про банкротство.

Это та же база, что вы просили проверить — заодно стало видно, какие дела в ней «не те». Разберём при созвоне.

Что дальше — от вас

• посмотреть обновлённые письма на схеме и дать правки, если что;
• два открытых решения: что считаем «возвратом» и нужно ли письмо при отказе в принятии заявления.

Коротко

Большой шаг по рассылке — письма написаны, и их можно прочитать.

Письма под каждый случай. Подготовили тексты на все ветки:

• должнику — когда заявление приняли: обычный вариант, вариант без указанной СРО и отдельный — когда банкротит налоговая;
• кредитору-заявителю — когда его заявление оставили без движения (обездвижка) или вернули.

К каждому письму — два коротких напоминания (на 3-й и 7-й день), если не ответили. Как только адресат ответил — больше не пишем.

Всё это собрано на одной наглядной схеме: путь дела → письмо. Наведите на ветку — подсветит всю цепочку; кликните на письмо — откроется полный текст.

Письма стали адресными

То, что вы просили — чтобы письмо было «не безликим»:

• обращение к директору по имени;
• «работаем в вашем регионе, знакомы с вашим арбитражом» (округ берём из номера дела);
• от лица ЮА «Правый Берег»;
• у кредиторских писем — предложение под конкретную причину (что именно не так с заявлением), и отдельно — что нам может быть интересен выкуп долга.

Когда отправляем

Уточнили правило: пишем не по факту, что дело просто появилось, а только когда есть определение суда — приняли заявление (→ пишем должнику) либо оставили без движения / вернули (→ пишем заявителю). Пока определения нет — ждём, не пишем.

Контакты и данные по делу

По большинству должников (примерно 9 из 10) собраны контакты для отправки.

Чтобы письма и разговор были предметнее, по каждому делу готовим дополнительную картину о должнике — финансы, другие судебные дела, сколько кредиторов уже заявили о намерении его банкротить.

Что дальше — от вас

• прочитать тексты (ссылка на схему выше) и дать правки;
• финальная подпись и контактный телефон для писем;
• пара решений: что считаем «возвратом» и нужно ли письмо в случае отказа в принятии заявления.

Коротко

1. Раньше рассылку готовили только по делам, где уже назначено заседание. Теперь можем писать всем компаниям сразу, как только против них подали заявление о банкротстве — на самой ранней стадии.
2. Контакты по таким компаниям собрали — адреса есть примерно у 93%.
3. Готов черновик письма — по каждой компании разбираем именно ЕЁ ситуацию и предлагаем защиту. Пример прислал тебе отдельно.

В чём смысл

Самый ранний момент — лучший, чтобы предложить помощь: на компанию только что подали на банкротство, она ещё не нашла юриста. Мы ловим это сразу и пишем адресно.

Про письмо

Не продаём в лоб. По каждой компании письмо объясняет её ситуацию из наших данных: кто подал на банкротство, какие у компании обороты и активы, что реально можно сделать на этой стадии (оспорить требования, повлиять на выбор управляющего, защитить активы). Дальше — предложение разобрать на короткой консультации без обязательств. Подпись — «Правый Берег», с 2008 года.

Отклики

Кто ответит — заявка сразу падает в мини-CRM: доска по стадиям (новый → консультация → встреча → в работе → выиграно/проиграно). Ни один отклик не потеряется.

Что нужно от тебя, чтобы запустить

1. Прочитать пример письма (прислал) — ок или поправить формулировки.
2. Подпись и контакт для ответа (имя + телефон/почта).
3. Кому слать: всем, против кого подали на банкротство, или с исключениями (например, не писать, когда банкротит банк или лизинг)?

Как пришлёшь — добиваем и запускаем.

Коротко

Раньше контакты собирались разово, и по свежим делам их почти не было — писать, по сути, некому. Теперь:

1. Контакты по делам в работе — ~92% должников (было ~40%).
2. Подключил DataNewton как источник контактов — он закрыл тех, кого остальные источники не находили.
3. Собирается само — каждые 6 часов новые дела автоматически дополняются контактами. База больше не «протухает».

Что было

Контакты собрались одним прогоном в середине мая. С тех пор появились сотни новых дел — и контактов по ним почти не было. Для рассылки это главный блокер: списки старые и дырявые, писать некому.

Что сделал

1. Запустил автоматический сбор. Каждые несколько часов бот берёт новые дела и сам ищет контакты должников сразу по нескольким источникам — госреестры, справочники, поиск.
2. Подключил DataNewton как источник контактов. Раньше мы брали из него только проверку — что адрес реально принадлежит компании. Теперь он отдаёт и сами контакты, и закрывает как раз тех должников, кого остальные источники не находят: по свежим делам добрал примерно 8 из 10 недостающих.

Что в итоге

• Дела в работе: ~92% должников с контактами (было ~40%).
• Новые дела дополняются автоматически, каждые 6 часов — без ручного запуска.
• Можно собрать контакты и точечно — кнопкой «Обогатить» в карточке (она теперь тоже использует DataNewton).

Что это значит для рассылки

По свежим делам почти всегда есть, кому писать — главный блокер по объёму снят. Списки теперь свежие и почти полные.

Что нужно от тебя: подтвердить финальные фильтры по 4 категориям (кому и что пишем) — после этого можно готовить отправку.

Коротко

Три вещи.

1. Сделал для тебя страницу со схемами — как бот находит дела, следит за ними и готовит рассылку. Открывается с дашборда, кнопка «📊 Процессы».
2. Обездвиж-дела больше не «протухают». Раньше через 30 дней дело снималось с мониторинга — даже если обездвижка ещё не разрешилась. Теперь следим дальше — до ~90 дней или пока не появится принятие/возврат.
3. Выручка — довёл до конца: все финансовые цифры в карточке всегда за последний поданный год.

1. Страница «Процессы»

Ты говорил, что в голове тяжело держать всю механику. Нарисовал — 7 схем простым языком: поиск дел, мониторинг, извлечение СРО, обездвиж, возвраты, заявители, рассылка. Плюс короткий список «что нужно от тебя».

Где. На дашборде вверху новая кнопка «📊 Процессы» (рядом с «Обновления»).

Как читать. Цвет = смысл: зелёный — дело движется, серый — отсеяли, бирюзовый — тебе придёт уведомление. Пунктир = ещё не запущено (например, заявители и автоматическая рассылка — пока в работе, и на схеме это честно отмечено пунктиром, чтобы ты не принял план за готовое).

2. Обездвиж-дела не теряются

Что было. Бот снимает дело с мониторинга через 30 дней без движения («устаревание»). Но обездвижка часто разрешается позже: заявитель устраняет недостатки, и принятие приходит через несколько недель. Дело к этому времени уже снято с мониторинга — и принятие (а значит, и алерт по СРО) мы бы пропустили.

Что сделали. Пока у дела есть неразрешённая обездвижка, продолжаем следить за ним и после 30 дней (проверяем раз в 12 часов). Как только приходит:
- принятие — дело продолжает обрабатываться как принятое, и прилетает алерт по нашим правилам (наша СРО / СРО не указана);
- возврат — дело уходит в категорию возвратов.

Дело перестаёт «висеть», как только обездвижка разрешилась (или если за ~3 месяца так ничего и не произошло — тогда отпускаем).

Что увидишь. Если дело было в обездвиже и через пару недель там появилось принятие с нашим СРО — придёт уведомление, как по обычному принятию. Раньше по «долгим» делам оно могло не прийти.

3. Выручка — последний поданный год

В прошлый раз починили саму выручку. Теперь довёл до конца: финансовая раскладка в карточке — выручка/активы, прибыль, дебиторка, основные средства и сравнение с прошлым годом — привязана к одному и тому же последнему поданному в ФНС году, а не к разным. Если последний год ещё не сдан — берём предыдущий. (Это про то, как показываются цифры; переотбора дел тут нет — про него ниже.)

Что дальше

• Обездвиж → письма. Размечаем 100 дел вместе, чтобы бот точно определял основание обездвижки. Дальше — шаблоны писем под каждое основание (должник / кредитор — письма разные).
• Выручка — отбор по свежим данным. На созвоне решаем: отсеивать ли дела по актуальным данным ФНС. Тот же СТРОЙДЕМСЕРВИС — по свежей выручке 2025 (68,8 млн) и активам (414 млн) порог не проходит; в списке он только потому, что когда-то прошёл по устаревшим цифрам 2024. Это аргумент отбирать по свежим данным — но сначала проверим всю базу, чтобы не выкинуть нужное.

Технические детали

TL;DR

С сегодняшнего дня мы видим намерения подать на банкротство (то, что публикуется на fedresurs.ru как «уведомление о намерении обратиться в суд» — ст. 7 №127-ФЗ) за 15 дней до того, как дело реально подаётся в КАД. Это пре-сигнал: должника ещё можно отследить, проверить актив-обязательства, выйти на покупателя/кредитора до того, как процесс попадёт в систему.

Pipeline крутится в шадоу-режиме с 28 апреля — за это время накопил 577 кейсов которые прошли фильтр (выручка / активность / организационная форма). Сегодня переключил в live — алерты по новым намерениям пошли в специальный чат для ревью. После ~недели обкатки подключу этот чат к твоему стриму.

Что было раньше

Pipeline видел банкротное дело только когда оно появлялось в КАД — то есть после того, как заявление принято к производству. Это уже поздновато:

• К моменту принятия Определения процесс развивается сам по себе. Намерение опубликовано ещё 15 дней назад на fedresurs.ru (это требование ст. 7 №127-ФЗ — кредитор обязан сначала уведомить).
• Эти 15 дней — окно, когда должник ещё не «загнан в угол». Можно поговорить с публикатором уведомления (часто это потенциальный заявитель — банк, крупный поставщик), понять реальную картину долга, проверить активы должника, выйти на покупателя цессии до того, как дело раздробится между АУ и кредиторами.
• Мы видели в КАД ~5,500 банкротных дел в год (актуальная статистика). А на fedresurs.ru публикуется ~19,400 намерений в год (стат за 2025). То есть для каждого банкротства публикуется ~3.5 предварительных намерения. 3.5x объём данных, которые мы не использовали.

Что мы сделали

Новый источник. Каждые 6 часов pipeline ходит на fedresurs.ru/backend/companies — это публичный API за анти-DDoS защитой, который возвращает топ-1001 компаний-публикаторов с самой свежей активностью. Сравниваем с предыдущим snapshot — новые компании (которые впервые опубликовали что-то за последние 24h) идут в дальнейшую проверку.

Фильтр. Для каждой новой компании проверяем:
1. Активна ли она по ФНС (status=ACTIVE)
2. Подходит ли её ОКОПФ (юрлица — да, физлица / некоторые формы — нет)
3. Выручка ≥ 300M ₽ или активы ≥ 1B ₽ (тот же порог что в КАД-discovery)
4. Конкретно это намерение — действительно ли «намерение обратиться в суд», а не другая тех-публикация (тип 35 = намерение кредитора, тип 36 = намерение должника на самобанкротство).

Если всё прошло — кейс попадает в новую панель /phase2/intention-seen на дашборде. Туда уже залито 577 случаев за прошедший месяц шадоу-наблюдения.

Алерты. Когда фильтр прошёл — Telegram-алерт. Содержит:
- ИНН + название должника
- Кто опубликовал намерение (кредитор → ИНН + название; «debtor» → должник сам на себя)
- Финансы (выручка, активы из бо.nalog)
- Дата публикации намерения (15-дневное окно от этой даты до автоматического истечения)
- Ссылка на fedresurs.ru

Что ты увидишь

Не сразу. Сейчас алерты идут в отдельный чат, где я их разглядываю первую неделю — смотрю, нет ли явных false-positive паттернов на live-данных (хотя шадоу проверка уже прошла на 577 кейсах). После ревью подключу твой Telegram — увидишь сразу новый поток алертов параллельно с текущими КАД-алертами.

Объём. По историческим данным шадоу-режима — ~50-65 алертов в день. Это сравнимо с текущим объёмом КАД-алертов которые ты получаешь. Если будет слишком шумно — донастроим пороги (выручка, ОКОПФ, дедупликация по INN, исключение банков/ФНС-инициаторов как в обездвиж-pipeline).

Где смотреть прямо сейчас. Если хочешь поковыряться до того, как алерты пойдут к тебе — открой /phase2/intention-seen на дашборде. Там 577 кейсов которые прошли фильтр за месяц шадоу — отсортированы по дате, можно открыть карточку, посмотреть финансы, перейти на fedresurs.

Лежащие в очереди 62 кейса (которые попали в panel но никогда не алертились потому что были обработаны в шадоу-режиме) не будут переподаваться — идемпотентность намерений по messageID не даст повторить. Эти 62 видны на дашборде, но Telegram-алерта по ним не будет. Только новые публикации, начиная с 06:00 UTC 26 мая.

Что НЕ изменилось

• Phase 1 КАД-pipeline (мониторинг определений, СРО-извлечение, обездвижка, возвраты) — работает как раньше, отдельным потоком.
• Финансовые пороги discovery (≥300M выручка / ≥1B активы) — без изменений.
• Telegram алерты по «нашим» делам (target СРО / СРО не указана) — без изменений.
• Дашборд (КАД-страницы, /costs, /updates) — без изменений.

Технические детали

Что было раньше

Когда новое дело попадает в watching / notified, наш пайплайн enrichment пытается найти email директора / контактного лица для последующей холодной рассылки. Шесть источников, ранжированные по доверию:

На 50 случайных INN из активного pool: 22 (44%) не нашли вообще ничего. Эти leads уходили в drop reason outreach.no_email и в рассылке не участвовали.

Что мы сделали

Добавили Tier 6 — Федресурс. Это публичный SPA-backend fedresurs.ru/backend/companies/{guid}, где для каждой компании в реестре банкротных событий есть блок contacts с email/site/phone.

{
  "ogrn": "5147746407815",
  "inn": "7727849985",
  "fullName": "ООО АУДИТ КОНСАЛТ",
  "contacts": {
    "email": "audit@centrcons.ru",
    "site": "auditcon.ru",
    "phone": "8(495)580-64-81"
  }
}

Логика:
1. Для каждого INN из enrichment job сначала прогоняем Tier 0-4 (как раньше).
2. Если хоть один tier нашёл email — Tier 6 не запускается. Post-condition gate. Экономит ~10 секунд per INN.
3. Если все вернули 0 — резолвим INN → GUID через /backend/companies?searchString={INN}, потом fetch /backend/companies/{guid} → если есть contacts.email — добавляем как email candidate с confidence=70 (на уровне 2ГИС).

Все найденные через Tier 6 контакты сохраняются с enrichment_method='federesurs' — видно в дашборде на /outreach/contacts, и можно фильтровать.

Что ты увидишь

На основе probe 50 случайных INN из активного pool:

То есть на каждые 50 новых INN — примерно 1 дополнительный email благодаря Tier 6. Скромный прирост, но бесплатный и одноразовый — раз настроили, работает без расхода квоты, без подписки, без maintenance.

Когда это запустится

Сейчас функция в коде, но выключена по умолчанию. Чтобы активировать в production cron:

# в .env на сервере
OUTREACH_ENABLE_FEDERESURS=1

Это включит Tier 6 для следующего тика email-enrichment cron. До этого момента ничего не меняется — старые источники работают как раньше.

Что дальше

• Запуск под наблюдением — флипнем OUTREACH_ENABLE_FEDERESURS=1 когда content side для рассылки будет готов (твоё подтверждение V7-шаблона + год начала практики + телефон).
• Метрика на дашборде — добавим в /costs или /outreach/queue счётчик «emails по source», чтобы было видно сколько Tier 6 даёт incrementally.
• Не ждём чудес — 2% прирост это не game-changer, но он бесплатный и не блокирующий. Запустим, посмотрим как ведёт себя на полном flow за неделю, если ROI хороший — оставим, если нет — выключим обратно.

Технические детали

Что было раньше

В предыдущем апдейте мы включили Tier 6 — Федресурс. На probe из 50 случайных INN он давал +1 incremental email из 22 «пустых» (т.е. где первые 5 источников ничего не нашли). 21 INN из тех 22 всё равно оставался без email.

list-org.com — это публичный community-агрегатор данных по российским юрлицам. На многих карточках компаний есть Email: поле, которое не публикуется ни на Федресурсе, ни в РКН, ни в rusprofile. Probe v3 на 12 контрольных INN показал:

Т.е. list-org даёт ~33% полностью новых email, плюс ~25% дополнительного подтверждения, что email в Федресурсе настоящий.

Что мы сделали

Добавили Tier 7 — list-org. Это полноценный SPA-скрейпер: открывает Chromium через Evomi residential proxy, ходит на list-org.com, ищет компанию по ИНН, парсит карточку.

https://www.list-org.com/search?type=inn&val=7727849985
  → редирект на /company/9302185
  → карточка с блоком «Email:», «Телефон:», «Сайт:»

Логика:
1. Прогоняем Tier 0-6 (как раньше + Федресурс).
2. Если хоть один tier нашёл email — Tier 7 не запускается. Тот же post-condition gate что и Tier 6. Экономит ~70 секунд per INN.
3. Если все вернули 0 — открываем list-org, фетчим карточку, парсим email через regex, фильтруем по deny-list (без noreply/admin/служебных доменов).
4. Сохраняем найденные email с enrichment_method='listorg', confidence=60 (на уровне rusprofile).

Антибот list-org

list-org защищается кастомным капча-механизмом (Sekuritxr + ACINT + DigitalCaramel поверх стандартного fingerprint check). При rate-limit редиректит на https://www.list-org.com/bot?from=<original_url> с чекбоксом «Проверка, что Вы не робот».

Мы капчу не решаем — мы её детектим и обходим. Логика:
- Каждая попытка получает свежую Evomi-сессию через суффикс _session-<random> в пароле прокси → новый exit IP.
- Если после goto URL содержит /bot — попытка считается провалившейся, ждём 15s, retry с новой сессией.
- До 3 попыток. Probe v3 показал: после 1-3 попыток с ротацией прокси всегда либо успех, либо данные не индексированы вообще (нет смысла повторять).

Никакого CAPTCHA-solving сервиса не нужно — block intermittent, ротация IP разруливает.

Smoke на проде сегодня

Прогнал на 3 ИНН:

Третий случай — это нормальное поведение «42% компаний на list-org без email» (помним, probe v3 показал 58% с email). Логика работает корректно: lookup_email вернул attempts=1, emails=(), phones=(5) за 11.5 секунд, ничего в outreach_contacts не записалось потому что email там реально нет.

Что ты увидишь

Tier 7 включен в production (OUTREACH_ENABLE_LISTORG=1 в .env, миграция применена). На каждом тике email-enrichment cron он будет дополнительно срабатывать на тех INN, где предыдущие 6 источников вернули 0 emails. Ожидаемый прирост: +33% от тех INN, что доходят до Tier 7.

В outreach_contacts начнут появляться строки с enrichment_method='listorg' (видно в дашборде /outreach/contacts, есть фильтр). Confidence=60 — на уровне rusprofile, ниже чем 2ГИС (70) и Федресурс (70), но выше чем web_search (30).

Тонкие моменты

• Список-орг медленный через Evomi. Сегодняшний смок-тест показал что главная страница загружается ~63 секунды через текущий Evomi exit pool. Поэтому таймаут на goto поднял с 45s до 90s. Один INN в худшем сценарии (3 попытки × ~90s × 3 страницы + 2 backoff'a × 15s) — это до 14 минут wall-clock. Реальный кейс с одной успешной попыткой — ~70-90 секунд.
• Tier 7 не блокирует cron. Если list-org вернёт homepage_err (как было в первом раунде смока до фикса таймаута) — error логируется, find_emails продолжает работу, в outreach_contacts тот INN остаётся с enrichment_method=NULL.
• Tier 6 + Tier 7 совместимы. Tier 7 запускается только если И прочие источники, И Tier 6 ничего не вернули. Это значит, что когда у компании есть запись в Федресурсе с email — Tier 7 не пытается.

Что дальше

• Наблюдать неделю — посмотреть на /outreach/contacts через 7-10 дней какой реальный прирост дают Tier 6 + Tier 7 combined на полном flow.
• Если list-org-block станет частым (>50% INN-attempts hit /bot?) — можно добавить дополнительные провайдеры прокси или увеличить MAX_ATTEMPTS до 5. Пока что probe v3 показал stable работу с 3 попытками.
• Метрика на /costs — добавить разбивку «emails по source» так же как для Tier 6 (вместе с ним), чтобы видеть incremental yield обоих новых источников.

Технические детали

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

18 мая в 13:00 MSK ты прислал серию определений с одинаковым возмущением:

• А56-51039/2026 ВИРАЖ — пришло в Telegram как «определение о принятии», но в PDF — определение об отказе в принятии заявления (размер долга ниже порога)
• А56-50051/2026 МХ1 ЛОГИСТИКА — то же самое: на самом деле отказ
• А60-17272/2026 УГПХ — это вступление в дело о банкротстве другого должника, а не самостоятельное банкротное дело. Не наш кейс — судьба компании зависит от чужого процесса.
• А40-132903/2026 АРС-СТРОЙ — это действительно принятие, и СРО там «ПАУ ЦФО». Правильный сигнал.

Из четырёх три пришли с неправильным типом. Реальный конверсионный сигнал — один.

Что было сломано

Pipeline смотрел на текст хронологии дела на kad.arbitr и пытался по подстроке «принят» отличить определение о принятии от прочих. Подвох: «определение об отказе в принятии» тоже содержит слово «принят». Тот же класс ошибки на «определение о вступлении в дело» — формально это «принятие заявления» (заявления о вступлении), хотя экономически — совсем другой кейс.

Простой substring-match ловил всё что пахло «принятием» и пихал в Telegram.

Что мы сделали

Разложили на 6 фаз. Все шипились последовательно 19 мая.

Phase 1 — Структурный экстрактор хронологии

Перешли от тыкания в HTML строки на структурированный обход DOM. Каждое событие в хронологии теперь сохраняется в отдельную таблицу chronology_events с типом события, датой, ссылкой на документ, текстом. Это даёт полную аудиторию: что суд делал по делу, когда, в каком порядке.

Phase 2 — Предварительный классификатор по структуре события

Вместо substring-match по одной строке — связка из правил:
- если в названии события есть «об отказе» — это отказ, какие бы там ни были последующие слова
- если есть «вступление в дело» — это вступление, не самостоятельное банкротство
- если ни то ни другое + есть «принят*» → возможное принятие, но с пометкой AMBIGUOUS

AMBIGUOUS уходит на LLM — финальный судья.

Phase 3 — LLM-классификатор: тип определения + СРО в одном вызове

Раньше LLM звался только для поиска СРО. Расширили промпт: один и тот же вызов теперь возвращает и ruling_type (тип определения из 8 вариантов: принятие / отказ / вступление / без_движения / возврат / признание_банкротом / постановление_о_принятии / другое), и sro_name.

Цена не изменилась — это тот же вызов с расширенным промптом, не дополнительный. Замер на 13 PDF: 100% правильных классификаций ruling_type.

Phase 4 — Telegram-фильтр на тип определения

Теперь Telegram срабатывает только на определения с типом из белого списка:
- определение о принятии к производству
- постановление о принятии (апелляционная инстанция)

Всё остальное (отказы / возвраты / вступления / без_движения / признания банкротом) — молча сохраняется в БД, виден в дашборде с правильным типом, но не шлёт Telegram.

Phase 5 — Бэкфилл исторических типов

Шипилась только сегодня. 551 определение которое уже было в БД переклассифицируется через тот же LLM-вызов: для каждого качаем закешированный на диске PDF, LLM решает, апдейтит rulings.ruling_type если новое значение отличается от старого.

Запускается завтра 20 мая в 07:00 UTC (через сутки после хронологического бэкфилла Phase 1, чтобы не пересекаться по ресурсам). Стоимость ~$2, время ~20 минут. Старые Telegram-сообщения не отзываются (мы их и не можем) — но в дашборде кейсы получат правильный тип.

Phase 6 — Единая терминология

Снэйк-кейс из БД (определение_о_принятии) больше не уезжает в интерфейсы как есть. Все три точки рендеринга — дашборд, Telegram, /issues — проходят через один общий словарь:

• определение_о_принятии_к_производству → «Принятие заявления к производству»
• определение_об_отказе_в_принятии → «Отказ в принятии заявления»
• определение_о_вступлении_в_дело → «Вступление в дело о банкротстве»
• определение_об_оставлении_без_движения → «Оставлено без движения»

В Telegram-сообщениях появилась новая строка «Тип акта:» прямо над СРО — видно сразу что за определение пришло. Раньше приходилось догадываться по тексту PDF.

Что ты увидишь

• ВИРАЖ (А56-51039): остался в БД как «отказ в принятии», Telegram больше не пришлёт повторно
• МХ1 ЛОГИСТИКА (А56-50051): то же — отказ в принятии
• УГПХ (А60-17272): вступление в дело, Telegram не сработает
• АРС-СТРОЙ (А40-132903): продолжит работать корректно — принятие, ПАУ ЦФО
• Все будущие определения: фильтр работает на потоке — отказы и вступления молча в БД, принятия в Telegram

20 мая после 07:30 UTC посмотри в дашборд старые кейсы — у них появятся правильные типы. Если найдёшь странности (например, было «принятие», стало «отказ»), пиши — это значит наш изначальный классификатор по хронологии ошибся, а LLM поправил.

Что НЕ изменилось

• Поиск СРО (словарный + LLM) — без изменений
• Расчёт «жирности» должника, фильтры выручки/активов — без изменений
• Multi-SRO «рулетка» (определение с несколькими СРО) — без изменений
• Стоимость LLM-вызовов не выросла: ruling_type идёт в том же вызове что и SRO

Что дальше

• 20 мая 07:00 UTC — бэкфилл 551 исторического определения (Phase 5). Логи в /data/logs/backfill_ruling_types_*.log на проде. Идемпотентность: повторный запуск не сделает второй вызов LLM на тот же PDF.
• Возможный side-effect: на «отказы» которые сейчас лежат в notified статусе, переклассификация изменит ruling_type, но статус кейса не изменится — он остаётся в дашборде как ты привык. Меняется только колонка «Тип определения».

Технические детали

Что было раньше

4 мая мы зашипили мульти-СРО («рулетка») — на определении суд иногда перечисляет 2–8 кандидатур СРО, и наша СРО может стоять не первой. Раньше система брала только первую СРО и молча теряла случаи, где наша на позиции 2–5.

Это работало для всех новых дел с 4 мая. Но для старых уведомлённых дел (до 4 мая) — мы видели в старом плоском поле sro_name только одну строку. Технически в PDF могло лежать 5 СРО, а ты видел одну. Никакого индикатора «здесь рулетка».

Ты это заметил 14 мая на деле А40-111932/2026 АО «РВС» (наше дело от 28 апреля) — там в PDF 5 СРО (ААУ ЦФОП АПК на позиции 2), а на дашборде показывалось только «ААУ ЦФОП АПК» — никакого сигнала, что это рулетка.

Что мы сделали

1. Backfill — заполнили мульти-СРО для исторических дел

Прошлись по всем 489 определениям в базе. Прочитали кэшированный PDF, прогнали через тот же экстрактор СРО, который работает в живом пайплайне с 4 мая (словарь + регекс), и записали все найденные СРО в таблицу ruling_sros с правильными позициями.

Результат:
- 361 определение уже имело мульти-СРО данные (это всё что после 4 мая — система их пишет автоматически)
- 91 определение не имело — и при пересборке нашлись СРО (от 1 до 8 на дело)
- 166 строк мульти-СРО добавилось в базу
- 35 определений прочитались, но СРО там действительно нет (отказы / возвраты без перечисления СРО — это правильное поведение)

Бэкфилл идемпотентный — повторный запуск ничего не дублирует.

2. Бейдж 🎰 в карточке дела

В колонке СРО рядом со старым тегом теперь появляется amber-бейдж, когда определение содержит ≥2 СРО:

• 🎰 ЦФОП — №2 из 5 — если наша СРО (ААУ ЦФОП АПК) в списке. Цифра — её позиция, вторая — общее количество. Это самый сильный сигнал: «здесь несколько кандидатур, и мы среди них».
• 🎰 8 СРО — если в списке нашей нет, но кандидатур несколько. Тоже полезный сигнал — рулетка крутится, можно зайти и побороться.

3. Фильтр «🎰 Несколько СРО (≥2)»

В выпадайке по статусу notified добавилась четвёртая опция (рядом с «Наши / без СРО» и «Чужие СРО»):

🎰 Несколько СРО (≥2)

Кликаешь — таблица сужается до дел, где в определении 2 и более СРО. На текущий момент таких дел 72.

Что ты увидишь

Открываешь denis.ownmail.dev → в шапке таблицы кликаешь Status → notified → 🎰 Несколько СРО (≥2).

Или сразу по прямой ссылке: https://denis.ownmail.dev/?status=notified&sro_filter=multi_sro

72 дела, отсортированные по дате — наверху самые свежие. У каждого видно полный список СРО (наведи курсор на бейдж — увидишь tooltip) и позицию нашей среди них.

Конкретные дела, на которые посмотри в первую очередь:

«Без ЦФОП» дела — это контекст. Мы там борьбу не ведём, но если хочешь ручную ревизию закрома — теперь можешь.

Что дальше

• Watchpoint на 24-48 часов: новые дела продолжают писать мульти-СРО в реальном времени (так уже работает с 4 мая, не меняется). Если за неделю новые multi-SRO кейсы перестанут появляться — это сигнал, что экстрактор что-то поломал и надо смотреть. Цифра «72» на фильтре должна потихоньку расти.
• Telegram-уведомление с позицией («(позиция X из N)») приходит только на дела, обработанные после 4 мая. Старые дела бэкфилл не ре-уведомляет — старые сообщения в Telegram остаются как были. Это намеренно: не хочу спамить тебя дублями.
• Если в карточке дела видишь, что СРО в ruling_sros неполный (например, в PDF реально 5 СРО, а у нас в базе только 3) — это или словарь не знает редкую СРО, или регекс не справился. Скинь номер дела — добавим в словарь, бэкфилл можно прогнать повторно.

Технические детали

Что заказывали

На звонке 5 мая ты сказал:

«давай попробуем, две штыки»

≈ 100 писем × 2 батча, чтобы посмотреть отдачу. Никакого SaaS, никакой автоматизации до сигнала — просто понять, конвертится ли холодный outbound в кейсы.

Под это собирался OUT — отдельная подсистема внутри проекта: 10 тикетов (OUT-01..OUT-10), которые превращают «есть телефон лида в outreach_contacts» в «письмо ушло, ответ классифицирован, кейс в воронке».

Что мы сделали

Pivot Coldy → Smartlead

Изначальный план был на Coldy.ai — российский cold-email-первичный сервис. На неделе они заблокировали API за самым дорогим тарифом (₽9 400/мес) + у саппорта неудобные часы. Архитектура у нас специально была сделана с swap'абельным ESP-адаптером, поэтому смена провайдера прошла без боли.

Пивотнули на Smartlead.ai Basic ($35/мес ≈ ₽3 300) — те же возможности, Inbox Rotation «из коробки» (несколько ящиков на одну кампанию), cold-permissive policy. Свой собственный mailbox denis@127-fz.com на Yandex 360 «Бизнесе» — провели полную DNS-настройку (MX/SPF/DKIM/DMARC, всё green по mxtoolbox), создали custom tracking-домен emailtracking.127-fz.com, две кампании-заготовки уже там.

9 тикетов выкачены отдельными ветками на GitHub

Каждый тикет проехал по протоколу Codex review → fixes → APPROVE → commit + push. Ни одна ветка ещё не вмержена в main — это для твоего ревью на GitHub.

Что нового на дашборде

Когда смержим ветки в main и задеплоим:

• /outreach/queue — твоя главная страница для outbound. Видишь pending-кандидатов, читаешь черновики, одобряешь либо отклоняешь. Bulk-approve кнопка («штык 100» одним кликом).
• /outreach/funnel — built → approved → sent → delivered → opened → replied → positive — с фильтрами по source/template/variant. Видишь, какой шаблон работает.
• /u/<key>/<token> — публичная страница отписки. Когда лид жмёт «отписаться» в письме, попадает сюда → суппресс-роу + русская страница «Отписка зарегистрирована» с упоминанием ст. 18 ФЗ-152.
• PATCH /api/outreach/messages/{id}/reply_classification — когда regex угадал неправильно, ты в очереди жмёшь «изменить ярлык» (positive ↔ negative ↔ unclear).

Защитные слои

В OUT-05 sender реализованы семь стадий перед каждой отправкой:

1. Malformed-guard — если в кандидате нет email или тело пустое → failed, без вызова ESP.
2. Suppression gate (первая) — если email/domain/INN уже в outreach_suppression → suppressed, без вызова ESP. Это срабатывает ПЕРЕД дневным капом и pacing'ом — отписки приоритетнее.
3. Daily cap — если за UTC-сутки уже отправлено OutreachConfig.daily_global_cap (по умолчанию 200) → кандидат остаётся approved (отложен на следующий тик), без отправки.
4. Pacing — задержка между кандидатами (30 сек по умолчанию). В рамках лимита Smartlead Basic 50 req/min.
5. Idempotency claim — INSERT в outreach_send_attempts с ключом outreach-c<id>-a<retry>. UNIQUE-индекс ловит дубликаты, если cron перезапустится в неудачный момент.
6. Resolve campaign_id — берёт OutreachConfig.smartlead_campaign_id_<source>. Если None и адаптер не manual_copy → failed.
7. ESP send — Smartlead. На 2xx → пишем outreach_messages, статус кандидата → sent. На отказ → бамп retry_count. На третьем фейле → failed (terminal).

Плюс kill-switch: OutreachConfig.auto_send_globally_enabled=false коротко замыкает всё ещё до фетча кандидатов — на случай ЧП.

Reply-классификатор знает русские падежи

Тонкость: «не интересно» содержит подстроку «интересно» — regex без правил отнёс бы это к positive. Поэтому отрицательный regex проверяется первым:

• не\s*(интересн|пиш|нуж|хоч) или отпи[сш] / удалит / спам / стоп → negative
• Если негатив не сработал, интересн / давайте обсуд / свяж / готов(ы|а)? / подробн → positive
• Иначе → unclear

Класс отпи[сш] покрывает обе формы — инфинитивный корень («отписаться») и повелительный («отпишите меня»). Слова отпис/удалит дополнительно триггерят авто-suppress — суппресс-роу прилетает сразу, без твоего вмешательства. спам/стоп относятся к negative, но автомат не давит — это спорные сигналы, ты решаешь руками через PATCH-override.

Smartlead — что прямо сейчас

Smartlead Basic         ✅ оплачен с корп-карты Ivinco
mailbox denis@127-fz.com ✅ SMTP+IMAP green, warmup ACTIVE
DNS                      ✅ MX/SPF/DKIM/DMARC verified mxtoolbox
tracking domain          ✅ emailtracking.127-fz.com → Smartlead
campaign rouletka_v1     ✅ id 3325689, DRAFTED, mailbox linked
campaign obezdvizhka_v1  ✅ id 3325690, DRAFTED, mailbox linked
warmup-фаза              🟡 14 дней (стартовала 2026-05-12)

14-day warmup — Smartlead будет нагревать ящик от ~5 писем/день до ~50/день. Это нужно чтобы Gmail/Yandex/mail.ru видели рост репутации постепенно, не пометили как спам. Через 14 дней (около 2026-05-26) — flip на active sends.

Что осталось до запуска

OUT-10 (последний тикет)

Smoke-харнесс: end-to-end проверка по всем 10 шагам спеки. Прогон в shadow-mode (send_adapter='manual_copy') на dev-БД, потом один тестовый send живьём на твой адрес, чтобы убедиться что цепочка не разорвалась. Шипну в течение недели.

Твои шаги, когда warmup закончится

1. Залить SQL триггеров в config/outreach_sources.yaml — какие именно кейсы должны попадать в рулетка_v1 (no-SRO leads) и обездвижка_v1 (stalled cases). Сейчас там stubs.
2. Заполнить тело шаблонов в БД — outreach_templates для cession_offer@v2 и т.п. Голос — твой; я могу помочь черновиком.
3. Дать команду flip-кнопке — OutreachConfig.auto_send_globally_enabled=true в config.yaml на Hetzner + рестарт web-сервиса. После этого Approve в очереди начинает реально отправлять.
4. Первая «штык 100» — ты заходишь в /outreach/queue?status=pending, читаешь черновики, жмёшь Bulk Approve. Sender cron в течение 5-10 минут (pacing=30s × 100 = ~50 мин) отправит всё через Smartlead.

Технические соображения

Multi-branch вместо одного epic-merge

Все 9 тикетов лежат отдельными ветками на origin. Можно мержить по одной в порядке OUT-01 → OUT-02 → ... → OUT-08 (или одной большой PR'кой с тага OUT-07, который содержит все предыдущие в истории).

IMAP пароль уже на Hetzner

YANDEX_IMAP_PASSWORD положен в /opt/scrapers/bankruptcy-monitor/.env сегодня. Залогинились — OK LOGIN Completed, 5 сообщений в INBOX (вероятно, тестовые от Smartlead warmup). Когда OUT-07 cron активируется, эти 5 классифицируются как unclear (нет матча в outreach_messages — мы пока ничего не отправляли) → orphan-skip, marked SEEN, без записей в БД. Чистая разминка.

Метрики проекта

Что было раньше

У нас 4 источника данных: kad.arbitr (определения суда), fedresurs (намерения о банкротстве), pb.nalog (налоговая задолженность через «Прозрачный Бизнес»), egrul (ЕГРЮЛ). Каждый когда-то писался отдельно — kad самый старый и боевой, egrul самый новый.

Проблема, которую ты сам не видишь, но которая ест время:

• У каждого источника свой стиль ошибок. kad может «лечь» из-за DDoS-Guard, fedresurs из-за Qrator, pb.nalog из-за CAPTCHA, egrul из-за лимита запросов. Каждый раз когда что-то падает, я лезу в логи и должен помнить, как именно этот конкретный источник обозначает «упал».
• Если по конкретному определению пришёл странный результат (например, СРО не та или ничего не нашли), нет простого способа «пересчитать с нуля». Нужно лезть в БД и крутить SQL.
• Не было видно, что вообще происходит. Все 4 шли через cron-скрипты, и единственный показатель здоровья — «есть ли свежие записи в БД». Если источник молчит — это потому что он сломался или потому что просто новых дел нет?

Это всё операционка, которая копится. Каждый раз когда мы добавляли новую функцию (вроде EN-cascade недавно), приходилось решать вопросы заново для каждого источника.

Что мы сделали

Большой рефакторинг — внутренний, тебя в день-в-день он не должен задевать. Но базу под следующие фичи положили.

1. Единый контракт для всех источников

Теперь все 4 источника живут под одним «договором»:

Это значит — когда мы в следующий раз будем менять, например, регекспы для извлечения СРО, я не лезу в 4 разных файла, а правлю один. И тесты автоматически прогоняются через все 4 адаптера.

2. Replay-кнопка на /ops/sources/{name}

На страницах /ops/sources/kad.arbitr, /ops/sources/fedresurs_spa, /ops/sources/pb.nalog, /ops/sources/egrul.nalog теперь видны последние 50 событий — что было сделано, когда, с каким результатом. Рядом с каждым событием — кнопка «Replay».

Зачем это нужно: если ты когда-нибудь заметишь, что по конкретному определению пришёл странный результат (например, парсер посчитал что СРО ЦФОП АПК, а ты вручную посмотрел — там МСРО Содействие), нажми Replay. Система пересчитает событие с текущей версией логики. Если регекспы или dict обновились — увидишь новый результат сразу. Без меня и без SQL.

3. Цветные бейджи здоровья на /ops/sources

На общей странице /ops/sources теперь у каждого источника видна цветная плашка:

• 🟢 зелёный (ok) — источник отвечает, латентность нормальная
• 🟡 амбер (degraded) — отвечает, но медленно или с ошибками (часто = CAPTCHA, временный rate-limit)
• 🔴 красный (failed) — упал, нужен оператор
• ⚪ серый (unknown) — нет данных о состоянии (например, мы ещё не делали health-check, или у источника нет дешёвого ping-эндпоинта как у EGRUL)

Это полезно когда я не у компьютера: ты сам можешь зайти и увидеть, что красное — это уже сигнал «звони Юджину».

4. Canary на kad.arbitr в shadow-режиме

Самая аккуратная часть. Старый монитор по kad.arbitr продолжает работать как обычно — ничего не меняется. Параллельно с ним мы запустили новый адаптер в shadow-режиме: он каждые 15 минут делает ровно то же самое, что старый монитор, но в БД ничего не пишет. Только сравниваем результаты.

Цель: 24 часа наблюдать, не разъезжается ли новый адаптер со старым. Если разъезжается больше 5% циклов — откатываемся, разбираемся, чиним. Если в пределах нормы — следующим шагом промоутим новый адаптер на место старого. Это уже отдельная задача после 24-часового окна.

Этот же подход применим к fedresurs/pb.nalog/egrul, но мы их пока не canary'им — у них тестовое покрытие через сравнения и контракт-харнесс, а risk-budget для shadow-сравнения на проде мы тратим аккуратно, по одному.

Что ты увидишь

Сегодня вечером и завтра

• На /ops/sources появятся цветные бейджи у kad.arbitr / fedresurs_spa / pb.nalog / egrul.nalog. На старте часть может быть серой — это норма, после первого health-цикла обновится.
• Зайдёшь на /ops/sources/kad.arbitr — увидишь таблицу последних 50 событий и кнопки Replay. Можно тыкать — это безопасно, не сломает прод. На каждый клик в БД остаётся след «replay started → success/failed», я смогу разобрать ретроспективно если что-то пойдёт не так.

В ближайшие 24 часа

Каждые 15 минут срабатывает canary по kad.arbitr — пишет одну запись в pipeline_events с пометкой step='canary'. Через сутки я гляну логи и:

• Если расхождений со старым монитором < 5% → планируем замену старого монитора новым адаптером (это будет следующий пост).
• Если ≥ 5% → откатываю canary, разбираюсь почему.

По остальным трём источникам

fedresurs / pb.nalog / egrul пока работают по-старому — старые скриптовые цепочки никто не трогал. Новые адаптеры готовы и протестированы, но включим их в прод следующим этапом, по одному, через тот же shadow-режим, чтобы не рисковать.

Что дальше

Через 24 часа: ретро по kad.arbitr canary, решение по flip-to-primary.

Следующая неделя: если kad.arbitr canary прошёл — повторяем для fedresurs / pb.nalog / egrul в той же последовательности.

Параллельно: теперь когда платформа есть, проще будет добавлять новые источники когда они нам понадобятся (например, ЕФРСБ через платный API, если решим, что оно того стоит — отдельный разговор).

Технические детали

1361795 cp5-10  canary cron + scope-boundary gate
52c5d66 cp5-09  health-status display + replay taxonomy validation
0b4d3da cp5-07  pb.nalog + egrul.nalog adapter migrations
a90e984 cp5-06  fedresurs_spa adapter migration
e6cb42c cp5-08  replay button UI
b42a409 cp5-05  replay dispatcher endpoint
82b1976 cp5-04  kad.arbitr adapter migration
7f87772 cp5-03  conformance test harness
8f59031 cp5-02  source registry auto-discovery + badge
d1b72fb cp5-01  BaseSource ABC + Pydantic v2 types

Что было раньше

Ты заметил, что с раннего утра 8 мая Telegram молчал — никаких новых уведомлений. Это не потому что нечего слать. Мониторинг упал в 06:23 UTC и 14 часов подряд каждый 15-минутный тик crash-ился на старте — браузер не мог открыть kad.arbitr.ru.

Когда я начал разбираться, всё выглядело как «прокси умер»: сайт Evomi у тебя не открывался, мне казалось — провайдер лёг. Но проверки показали другое:

• Evomi отвечал HTTP 200 за 122 мс на запрос их собственного сайта
• curl через тот же Evomi-прокси открывал kad.arbitr.ru без проблем (TLS handshake, 200 OK)
• А Chrome через тот же прокси падал с ERR_TUNNEL_CONNECTION_FAILED

Прокси работал. Падал именно браузер.

Параллельно у нас была другая задача — новый слой проверки должников через DaData (EN-cascade). Когда наша основная база bo.nalog возвращает 404 на ИНН (а это бывает у банков, страховых, недавно открытых ООО), мы помечали кейс как inn_not_in_db и забывали. Получалось, что жирные ACTIVE-юрлица тихо проваливались мимо, и ты их не видел в воронке. Этот слой был готов, но не «прожжён» в проде до сегодня.

Что мы сделали

1. Починили мониторинг (P0)

Корень проблемы оказался хирургическим: библиотека playwright-stealth, которую мы накладывали поверх patchright (наш undetected-движок). Patchright инжектит скрипт через свой внутренний URL patchright-init-script-inject.internal. С прокси на уровне браузерного контекста этот internal-запрос шёл через Evomi — а Evomi (как и любая residential-сеть) не умеет резолвить такие нерутируемые *.internal хосты. Каждый запрос ронялся, а с ним — вся загрузка страницы.

Patchright и так stealthed — двойной патчинг был антипаттерном. Убрали playwright-stealth из обоих клиентов (kad-monitor и casebook-discovery). Воспроизвели на проде минимальным репро и подтвердили — без stealth Chrome через Evomi проходит DDoS-Guard и открывает kad.arbitr.ru за 7 секунд.

Результат: прод восстановился в 03:37 UTC. Накопившиеся 488 кейсов сейчас догоняются. К утру 9 мая по Москве Telegram опять должен зашевелиться.

2. Активировали DaData identity layer

Логика проста: если bo.nalog не нашёл ИНН — спроси у DaData. Их ответ говорит:

• ИНН относится к ACTIVE юрлицу (ООО/АО/ПАО, не ИП и не физлицо) → мы зря его пропускали, надо мониторить
• ИНН найден, но юрлицо в LIQUIDATED / BANKRUPTCY / UNKNOWN → это уже не наша целевая аудитория, исключаем явно
• ИНН не найден вообще → оставляем как было, на будущий слой (web-search, PDF-parse)

3. Прогнали репетицию по существующим 152 кейсам

Это всё кейсы, помеченные inn_not_in_db за последние 4 месяца — из тех, что когда-то прошли первичный фильтр, но провалились на финансовой проверке.

Подчеркну: 109 кейсов — это потенциальные сделки, которые ты бы не увидел старой логикой. Прогон сделан в режиме «только посмотреть» (dry-run) — пока никаких изменений в базе нет.

Что ты увидишь

Сегодня вечером и завтра утром (МСК)

• В Telegram пойдут уведомления, которые накопились за 14 часов простоя — это backlog мониторинга, а не новые кейсы. Ничего не теряется, всё просто отложилось.
• На дашборде «watching» цифра колыхнётся вниз: за 14 часов часть кейсов ушла в notified/returned/rejected без Telegram, и теперь обработается пакетно.

Через ~24 часа (после стабильного наблюдения)

Я запущу второй прогон по тем же 152 ИНН в режиме «применить» — и 109 «жирных» кейсов перейдут в watching с отметкой «найдено через DaData identity». Дальше они работают как обычные watching-кейсы: monitor каждые 15 минут проверяет, не появилось ли определение, и шлёт тебе Telegram если СРО подходит.

На дашборде

• В «Сkipped» появится новая под-категория inn_not_in_db_dadata_inactive (35 кейсов) — это явно мертвые юрлица, чтобы ты не путал их с настоящими «не нашли»
• В «Watching» — новые 109 кейсов с пометкой qualified_by_dadata_identity

Что дальше

Ход 1 (через 24h): запуск backfill в режиме --apply. Тебя дёрну в Telegram когда буду готов — глянешь dry-run output (109 имён) на разумность.

Ход 2 (через 7 дней): замер реального recovery rate. Если из 109 в watching-статусе у нас будет приличная конверсия в notified (например, ≥30%) — слой DaData оправдал себя, движемся к следующему: web-search для тех 8% которые DaData не нашла.

Если recovery rate окажется низким (< 30%) — добавим следующий слой (Tavily / Perplexity web-search) для этих 8 «оставшихся». Это уже отдельный эпик.

Что было раньше

Предыдущие шаги дали два слоя видимости:

• CP-1 — реестр запусков. Таблица pipeline_runs, страница Ops · Runs. Видно когда стартанул cron_monitor или intention_stream, сколько шёл, упал или нет.
• CP-3 — админ-страницы поверх реестра. Расписание (Ops · Jobs), реестр источников и расходов (Ops · Sources), заглушка под детальный пробег /ops/runs/{id} с amber-плашкой «Per-event drill-down requires CP-2 ship».

Дыра в середине: «а что задача внутри себя сделала?» Прошёл ли intention-sweep по 700 компаниям? Сколько раз LLM вызывался и зачем? На каком шаге catalog-скрейпер уперся в Qrator-блок? Был ли это уже третий fetch_timeout подряд? — Всё это жило в логах в /var/log/bankruptcy-monitor/*.log. Чтобы что-то найти — grep-ать на сервере. Структурированного «а сколько у нас было intention.fetch_fail за вчера» — не было.

Плюс ошибки: если cron упал — в pipeline_runs.status='failed', exit_code какой-то, и всё. Стектрейс — найди его в логе. Никаких алертов.

Что мы сделали

Восемь подзадач, все на проде. Эпик #185 закрыт.

1. Таблица событий

Новая pipeline_events в data/observability.sqlite (отдельный файл от cases.sqlite — чтобы запись событий не конкурировала за блокировку с основной БД). 16 колонок: run_id (linkage с pipeline_runs), source/step/action (saved/dropped/errored/started/finished), reason_code (catalog.qrator_block, llm.over_budget, etc.), payload_hash + payload_size, error_msg, created_at, seq для упорядочивания внутри пробега.

Реестр валидных reason_codes — отдельный файл src/observability/event_reasons.py с 20 кодами, по семантическим доменам: catalog.* (6 кодов), intention.* (2), llm.* (8), provider.* (2), run.* (2). Любой неизвестный код в dev-режиме крашит ассерт; в проде — логируется в stderr и пропускается (fail-open).

2. Hot-path API

Функция track_event(...) синхронная, async-safe by construction: на горячем пути только in-memory append + микросекундный лок, ноль I/O. Воркер-тред каждые 200мс / 100 событий / на severity=high сливает буфер в SQLite одним батч-инсертом. Если процесс падает — atexit-хук сливает оставшееся.

run_step — контекстный менеджер обёртка вокруг произвольного блока кода — автоматически парные started/finished или started/errored события, замеряет latency_ms, ловит исключения.

3. Sentry init с PII-скраббером

init_sentry() в src/observability/sentry_init.py. Lazy import — sentry-sdk не подгружается если DSN не настроен. На инициализации: дефолтные интеграции отключены (никакие фреймворковые хуки не успеют схватить тело request'а до нашего скраббера); единственный хук — before_send, который:

• проходит по всему event (extra / contexts / tags / request / user / breadcrumbs / stacktrace.vars) и заменяет значения по ключам, матчящим PII-регекс — phone|email|inn|ogrn|kpp|passport|address|fio|otchestvo|surname|familia плюс кириллические эквиваленты фио|отчество|адрес|инн|кпп|огрн|телефон|почта|паспорт|счет|фамилия — на [REDACTED]
• считает стабильный fingerprint = SHA-256 от (exception_type, message[:200], top-3 stack frames «module::function») и режет до 10 событий per-fingerprint per-час. Sentry-шный event_id — UUID4 на каждое срабатывание, для группировки бесполезен; наш fingerprint склеивает повторы из одного места кода

Результат: даже если кто-то случайно сунет ИНН в logger.info(...) — в Sentry улетит [REDACTED]. И если runaway-цикл будет генерить одно и то же исключение 1000 раз в минуту — Sentry получит ровно 10 за час.

4. Ретенция

Суточный cron 35 4 * * * запускает scripts/cron_observability_retention.sh → удаляет события старше 90 дней и пробеги старше 365 дней. Пишется log в /var/log/bankruptcy-monitor/observability_retention.log. Если data/observability.sqlite залочен — таймаут 60с (busy_timeout PRAGMA), потом лог + следующий тик попробует снова.

5. Инструментация: 5 чокпоинтов

Места, где пишется событие на каждое решение — расставлены по «горячим» точкам пайплайна:

• catalog-скрейпер (_CatalogScraperBase): на каждой странице — started; на каждой строке — saved (записалось) или dropped catalog.freshness_unchanged (запись не изменилась); на ошибках — errored catalog.qrator_block / catalog.fetch_timeout / catalog.parse_error; при попадании в watermark — finished catalog.watermark_caught_up; при date_from-cutoff — dropped catalog.before_date_from
• intention-sweep: started / finished бэндят сам пробег; errored intention.fetch_fail на каждый failed snapshot fetch или per-guid publication fetch; dropped intention.filter_miss если discovery-filter отказал кейсу
• LLM-обёртка (call_with_audit): 11 точек — errored llm.api_key_missing / llm.over_budget / llm.prompt_template_error / llm.openrouter_exception / llm.parse_failed; dropped llm.confidence_low / llm.captcha_unsupported. Успешный вызов НЕ пишет в pipeline_events — для этого есть llm_extractions (cost, latency, raw_quote)
• provider health: errored provider.degraded только в момент пересечения порога (когда threshold впервые крестится за час). Single-probe failure → пишется только в provider_health_log, в pipeline_events не дублируется
• refresh-оркестраторы (refresh_catalog, refresh_cession_matches): started / finished на каждый пробег; errored run.early_abort если что-то упало до основной работы (например, BrowserSession.__aenter__ не смог поднять браузер)

6. Бенчмарк под нагрузкой

Перед деплоем — scripts/benchmark_observability_writes.py: на копии observability.sqlite запускается синтетическая нагрузка: Worker A симулирует cron-tick раз в 5 секунд, Worker B пишет 4 потока × 250 событий в секунду, Worker C читает. Замеряется p50/p95/p99 latency для pipeline_runs И pipeline_events. Verdict-функция: ratio > 1.5 → BLOCK; > 1.0 → APPROVE_WITH_CAVEATS; ≤ 1.0 → APPROVE. На бейслайне: APPROVE.

Что ты увидишь

В верхнем меню как было — три Ops-кнопки. Визуально на дашборде ничего не поменялось.

Под капотом — на текущий момент уже 137+ событий в pipeline_events за первый час после деплоя (события набегают на каждый cron_intention_stream, cron_p5_bl_* и cron_monitor тик). Каждое событие имеет run_id, который джойнится с pipeline_runs.id для того же пробега — это означает, что когда CP-3-страница /ops/runs/{id} подключит этот источник, на ней будет live-таймлайн.

Sentry уже подключён. Тестовое событие проверено — пришло в дашборд с правильным release (git-SHA), environment=production, тегом smoke_test=true чтобы фильтровать «не это», и со скрабленным контентом. Если что-то реально упадёт в проде — увидишь его в Sentry как Issue с email-нотификацией.

Что дальше

• CP-3-страница /ops/runs/{id} уже шипалась с amber-плашкой «Per-event drill-down requires CP-2 ship». Эта плашка теперь устарела — следующий шаг (отдельный мини-эпик) подключает источник pipeline_events к шаблону страницы и рисует гистограмму типов событий + raw-таймлайн. Спека готова, в очереди.
• Бейслайн lock-contention на cases.sqlite снят перед деплоем: p95=0ms, max=8ms, 0 таймаутов на 100К попыток за 30 секунд. Через 7-14 дней под реальной нагрузкой пересниму и сравню — если p95 уйдёт за 50% бейслайна, значит пишущий воркер событий бьётся за блок с основной БД (хотя они в разных файлах — поводов для контеншна не должно быть).
• Бэкапы data/observability.sqlite.backup-pre-cp2-20260508T182456Z (184КБ) + cases.sqlite.backup-pre-cp2-... (52МБ) лежат на Hetzner на случай отката. Снять можно после 15 мая.
• Sentry квота — Developer-план, 5К событий/мес. С нашим per-fingerprint rate-limit (10/час/класс) этого хватит на ~50 разных классов ошибок постоянно работающих. Если упрёмся — апгрейд на Team-план $26/мес.

Технические детали (для интересующихся)

Что было раньше

Прошлый шаг (CP-1) дал страницу Ops · Runs — список запусков всех 32 фоновых задач. Видно, что когда стартовало, сколько шло, упало или нет.

Но оставались дыры:

• «А когда они запустятся в следующий раз?» — расписания крона жили в crontab -l на сервере, не в UI. Чтобы посмотреть когда следующий пробег monitor, нужно было лезть по SSH.
• «Сколько мы тратим на каждый источник?» — Evomi-прокси, AstroProxy, 2captcha, OpenRouter, ЕГРЮЛ, Контур — расходы рассыпаны по разным таблицам. Не было единого ответа на вопрос «что у нас вообще есть и что почём».
• «Что именно сделал этот конкретный запуск?» — клик по строке в Ops · Runs ничего не давал. Только имя + длительность + статус.

Что мы сделали

Три новые страницы плюс реестр источников под капотом.

Ops · Jobs — расписание всех 32 задач

Читает cron_manifest.yaml (декларативный реестр всех cron-задач, заведённый в CP-1) и для каждой строки показывает:

• имя + русское описание
• расписание (cron-выражение */15 * * * * и т.п.)
• когда следующий запуск в UTC — посчитано через библиотеку croniter
• источники данных — какие именно сайты/API задача дёргает (например monitor → kad.arbitr)
• тип лока (single-instance / parallel)
• путь к bash-обёртке для отладки

Если cron-выражение битое или cron_manifest.yaml не парсится — страница не падает 500-кой, а показывает плашку с ошибкой и рендерит остальные строки.

Ops · Sources — реестр источников и расходы

Самая «жирная» страница. Группирует 24 источника по категориям:

• Источники данных (17) — kad.arbitr, casebook.ru, fedresurs.ru/backend, pb.nalog.gov.ru, ЕГРЮЛ, ФНП, Контур.Фокус и т.д.
• Инфра-провайдеры (7) — Evomi (residential proxy), AstroProxy, Hetzner, Selectel, 2captcha, OpenRouter (LLM fallback), Sentry

По каждой строке: тип (бесплатный скрейп / платный API / гибрид), статус (активный / устарел / отключён), коммит-бюджет в месяц, фактический расход с 1-го числа, дата последнего обновления записи.

Особый случай — три прокси-провайдера: их трафик пишется в общую таблицу без атрибуции по провайдеру (так исторически устроено), поэтому сверху рендерится строка «Unallocated proxy MTD: $X», а в каждой из трёх отдельных строк — заглушка (included above). Это не баг, это честное отображение данных.

2captcha считается отдельно — там MTD это сумма положительных дельт баланса (фильтрует пополнения, оставляет только реальный сжог). Если снапшотов меньше двух — показывается «balance only — burn calc requires 2 snapshots» вместо мусора.

Если cases.sqlite залочена долгим cron-ом — таймаут 5 секунд, потом ячейки MTD рендерятся как «Cross-DB read unavailable». Страница всё равно открывается.

Ops · Runs/{id} — детальная страница по одному запуску

Клик по любой строке в Ops · Runs теперь открывает детальную страницу. Рендерит все метаданные конкретного пробега: имя, статус, время старта/финиша, сколько шёл, сколько ждал блокировку основной БД, какой git-SHA крутился, путь к лог-файлу, код выхода.

Если CP-2 (следующая фаза, расширение телеметрии — детализация по обработанным записям) ещё не докатилась — страница показывает амбер-плашку «Per-event drill-down requires CP-2 ship». Когда CP-2 приедет, на той же странице сверху появится гистограмма по типам событий, снизу — пагинированный raw-таймлайн.

Реестр источников под капотом

Заведена новая таблица source_registry в data/observability.sqlite. 24 строки засеяны: имя, отображаемое имя, тип, категория, кост-модель (JSON), путь к Python-модулю-владельцу, статус. Имена нормализованы — twocaptcha (а не 2captcha), kontur_basic (а не kontur_focus), proxy_seller помечен deprecated (мигрировали на Evomi 30 апреля).

Cross-validation между реестром и cron_manifest.yaml: если cron-задача упоминает source_keys: ["kad.arbitr"], но в реестре такого имени нет — линтер ругается. Это защита от очепяток.

Что ты увидишь

В верхнем меню дашборда теперь три кнопки на префиксе Ops:

• Ops · Runs (с CP-1) — список запусков
• Ops · Jobs (новое) — расписание
• Ops · Sources (новое) — источники и расходы

И клик по любой строке в Ops · Runs теперь ведёт на детальную страницу /ops/runs/{id} — раньше это была пустая ссылка.

На текущий момент Ops · Sources уже показывает живые цифры:

• Evomi-прокси — $49.99/мес коммит, фактический расход с 1 мая в строке Unallocated proxy MTD
• AstroProxy — $20/мес коммит
• 2captcha — текущий баланс + сжог за месяц через дельты
• OpenRouter (LLM fallback) — фактический MTD из таблицы llm_extractions WHERE accepted=1
• Hetzner — $8/мес
• Selectel (RU-фасад) — $9/мес

И 17 строк источников данных — kad.arbitr, casebook, fedresurs, pb.nalog и остальные — у них $0/мес коммит (бесплатный скрейп), но видна дата последнего обновления записи и владелец модуля для отладки.

Что дальше

• 24-часовой watch до 9 мая ~07:00 МСК — следим чтобы /ops/sources не таймаутил на cases.sqlite под нагрузкой (там сейчас ~50 МБ и параллельные мониторинговые писатели)
• CP-2 (следующая фаза) уже частично замёрджена — пишет события на каждый шаг внутри запуска. Когда докатится полностью, страница /ops/runs/{id} оживёт: гистограмма событий + raw-таймлайн вместо текущей амбер-плашки
• Бэкапы /var/backups/bankruptcy-monitor/{observability,cases}_cp3_pre_*.sqlite лежат на Hetzner до 15 мая на случай отката, потом удалю вручную

Технические детали (для интересующихся)

Что было раньше

У нас 32 фоновых процесса, которые крутятся по расписанию: одни каждые 15 минут (мониторинг kad.arbitr), другие раз в день (поиск новых дел на casebook.ru, парсинг определений), третьи раз в неделю (обновление "Прозрачного бизнеса"), четвёртые раз в месяц (ЕГРЮЛ, ФНП).

Если что-то ломалось — узнавали либо из Telegram-алерта (если алерт настроен), либо случайно при просмотре логов в tail -f data/logs/*.log. Не было общего ответа на вопрос «всё ли запустилось сегодня?» — приходилось проверять каждый лог-файл отдельно.

Что мы сделали

Каждый раз, когда запускается любая из 32 задач, теперь записывается отдельная строка в журнал запусков:

• имя пайплайна (например monitor, discovery, p5_bl_biddings)
• когда запустился (с миллисекундной точностью)
• сколько шёл (длительность)
• статус: ok (отработал чисто) / failed (упал с ошибкой) / running (ещё идёт)
• код выхода (0 = успех, 1 = ошибка, 130 = прерван по Ctrl+C, 143 = убит сигналом TERM)
• git SHA — какая версия кода крутилась
• путь к лог-файлу для детальной отладки

Журнал хранится в отдельном файле базы (data/observability.sqlite), чтобы не мешать основной бизнес-БД (data/cases.sqlite). Это важно: даже если журнал сломается, сами задачи продолжат работать как обычно — телеметрия никогда не блокирует прод.

При сбое задачи (исключение в коде, kill -9, Ctrl+C) трап-обработчик в bash успевает записать failed + код ошибки прежде чем процесс завершится. Если же существующая задача уже имела свой обработчик выхода (например, cron_monitor.sh снимает lockfile при выходе) — наш обработчик корректно вызывает её первой и только потом пишет в журнал.

Что ты увидишь

Новая кнопка Ops · Runs в верхнем меню дашборда (https://denis.ownmail.dev) → откроет страницу со списком всех запусков:

• На каждой строке: что за пайплайн (русское описание простым языком), когда запустился (московское время), сколько шёл, успешно или нет (цветной индикатор)
• Фильтры: только running / только failed / по имени / лимит количества
• Сортировка: новые сверху или старые сверху
• Под капотом — это реалтайм из новой таблицы pipeline_runs

Например, на текущий момент уже видно:
- monitor → "kad.arbitr.ru мониторинг каждые 15 минут — новые определения по watching делам", запустился 03:52 МСК, шёл 1 мин 29 сек, статус ok
- archive_old_no_sro → "Архивация notified-без-СРО старше 14 дней", запустился 03:39, шёл 1 сек, ok (заархивировал 1 кейс)

Что дальше

• 24-часовой watch-период до 8 мая ~04:00 МСК — все 32 задачи должны зарегистрироваться хотя бы раз
• После — финальная проверка: не выросло ли время блокировок основной БД из-за новой телеметрии. Pre-deploy замер показал p95 = 1 мс, 0 таймаутов на 950 тыс попытках — должно остаться так же
• В планах CP-2 (расширение телеметрии — детализация по обработанным записям внутри каждого запуска) и CP-3 (детальная страница по конкретному запуску — drill-down + replay button)

Технические детали (для интересующихся)