# «Лиды не идут с 3 июня» — РАЗОБРАНО (23.06.2026): решение владельца + технические заметки

> ✅ **ВЕРДИКТ (подтверждено владельцем 23.06.2026):** лиды не идут, потому что **владелец сам
> выключил проекты** — это **намеренное бизнес-решение, НЕ дефект**. Остановку лидов чинить не
> нужно. Технические находки ниже (FN-SESSION, молчаливый дроп) остаются как **отдельные заметки**,
> они НЕ являются причиной остановки и НЕ требуют срочного действия.

**Дата:** 2026-06-23. **Метод:** read-only разведка боевого (`ssh liderra-prod`, psql суперюзером — SELECT, прод не менялся) + подтверждение владельца. **Кодовая фраза стены:** «роутер-наставник».

**История этого файла:** изначально (утро 23.06) он опровергал вывод из
`docs/superpowers/specs/2026-06-21-acceptance-RUN-report.md` /
`docs/superpowers/runbooks/2026-06-22-FN-SESSION-diagnosis-and-ops-fix.md` («бизнес-решение омеги,
не дефект») как «реальный инцидент». **Владелец 23.06 уточнил: проекты выключил он сам.** Значит
по сути исходный вывод «бизнес-решение, не дефект» был ВЕРЕН; неверны были только формулировка
«омега» (выключены проекты главного клиента **tenant 2**, не только омеги tenant 25) и трактовка
как «инцидента». Технические факты прода ниже **сохранены** — они корректны и полезны как контекст.

---

## Что проверено живьём (доказательства, 23.06)

| Факт | Значение |
|---|---|
| Последняя сделка в БД | id 1026, **2026-06-03 05:42:15**, tenant 2 |
| Сделки по дням июня | 01=96, 02=54, 03=56, **04–23 = 0** (ноль 20 дней) |
| `supplier_leads` (входящий сырой поток) | май28=161, май29=129, июн1=171, июн2=92, июн3=112, **июн4–22 = 0**, **июн23 = 2** |
| Последний лид до разрыва | id 1755, 2026-06-03 09:57 |
| Сегодняшние 2 лида | id 2023 (03:01) + 2024 (03:18), platform B2, `supplier_project_id=495`, **`deals_created_count=0`, `error=NULL`** |
| supplier_project 495 | omega B2, `unique_key 791353XXXXX` (телефон-источник, маска), subject [29], `sync_status=ok`, `last_synced 22.06 15:05:48` |
| Проект 188 (омега) | tenant 25, `is_active=true`, **`preflight_blocked_at=2026-06-22 15:05:34`**, `daily_limit_target=50` |
| Tenant 25 (омега) | баланс **300 ₽**, `frozen_by_balance_at=NULL` |
| Снимок маршрутизации проекта 188 на 22–24.06 | **нет** (пусто) |
| Все снимки на 23.06 | ровно 1 — проект 135 (tenant 2), лимит 20 |
| Tenant 2 (главный клиент) | баланс **1 835 400 ₽**, не заморожен, 117 проектов, **3 активных** (на 21.06 было 0), 0 заблокир. |
| Исходящий синк к поставщику | `supplier_projects`: 299 ok / 95 pending, max `last_synced 22.06 17:01` |
| Браузер Playwright (www-data) | на месте, 21.06 12:36; ошибок `PlaywrightBridge exit` после 21.06 12:36 — **0** |
| Свежий шум 23.06 | `Portal returned login page after refresh on /admin/report/save-report` ×7 (04:00–07:00) |

## Картина (причина — решение владельца; ниже технический контекст)

> ✅ **Причина остановки лидов = владелец сам выключил проекты (намеренно, подтверждено 23.06).**
> Это первично. Слои A/B/C ниже — технический контекст вокруг, НЕ причины и НЕ требуют срочного
> действия. Слой A (FN-SESSION) — уже починен; B/C — мелкие заметки.

**A. Июнь 4–21 — был сломан ИСХОДЯЩИЙ синк к поставщику (FN-SESSION) — УЖЕ ПОЧИНЕНО.**
Браузер `chrome-headless-shell` пропал из кэша www-data → `RefreshSupplierSessionJob`/синк падали →
конфиг проектов не доезжал до кабинета. На стороне поставщика проекты ушли в off (ПИЛОТ.md 21.06:
все 455 выключены), входящих лидов — ноль. Браузер вернули 21.06 12:36, синк прошёл 22.06.
**Вывод runbook'а «FN-SESSION к остановке лидов отношения не имеет» — неверен:** период
сломанного браузера (14–21.06) ровно накрывает начало разрыва, а исходящий путь синка шёл через
тот же Playwright.

**B. Июнь 22–23 — заметка: лид на заблокированную омегу роняется МОЛЧА (мелкий нюанс наблюдаемости).**
Сегодня прилетели 2 лида на supplier 495 = omega B2, но проект 188 с 22.06 15:05 стоит
`preflight_blocked_at` (баланс 300 ₽ < суточный лимит 50 × ~70 ₽). Заблокированный проект не
попадает в вечерний снимок маршрутизации → в `RouteSupplierLeadJob` лид падает в
`no_snapshot_skipped`. **Это `Log::info`, а прод пишет от `warning` → в лог НЕ попадает.**
Итог в БД: `deals_created_count=0, error=NULL`, ни строки в логе. Раз проект выключен намеренно —
это ожидаемо; единственный мелкий хвост — **наблюдаемость** (если захочется видеть такие случаи,
поднять лог до `warning`). Это контекст к пункту L.

**C. Главный клиент tenant 2 — проекты выключены владельцем намеренно.**
Баланс 1.8М, не заморожен; 3 проекта снова активны (проект 135 даже имеет снимок на сегодня,
лимит 20). Лидов для tenant 2 нет, потому что **владелец сам выключил проекты** (на 21.06 было
0 активных из 117; supplier-сторона выключена). Это решение владельца, не сбой. Если решит
включать — включает по своему усмотрению.

## Скрытый дефект диагностируемости (находка этой поправки)

Заблокированный/беснимочный проект, по которому поставщик ПРОДОЛЖАЕТ слать лиды, роняет их через
`Log::info('supplier_lead.no_snapshot_skipped')` — невидимо на проде (`LOG_LEVEL>=warning`).
То есть «деньги клиента простаивают + поставщик уже шлёт» = полная тишина в наблюдаемости.
**Кандидат на фикс (докалка, TDD):** поднять до `Log::warning` (или метрику/алерт), когда лид
приходит на проект без снимка/заблокированный — чтобы такой случай был виден сразу.

## Статус

**ЗАКРЫТО по сути: остановка лидов — намеренное решение владельца (он выключил проекты), НЕ дефект.**
Чинить «лиды» не нужно. Остаются только мелкие необязательные хвосты, НЕ блокеры:
- Омега (tenant 25 / проект 188) под `preflight_blocked_at` (баланс 300 ₽) — если владелец захочет
  её включить, разблокировать (пополнить / снять блок). Пока проект выключен намеренно — не трогать.
- Диагностируемость молчаливого дропа (`no_snapshot_skipped` = `Log::info`) — **необязательное**
  улучшение наблюдаемости (докалка, TDD): поднять до `warning`, когда лид приходит на
  беснимочный/заблокированный проект. Низкий приоритет (раз проекты выключены намеренно).
- Профилактика рецидива A — шаг `playwright install под www-data` в деплой-пайплайн (ops владельца).
