← все проектыfeaturefeaturefeaturefeaturefeaturefeaturefeaturefeaturefeaturefeaturefeaturefeaturefeaturefeaturefeaturefeaturefeaturefeaturefeaturefeaturefeaturefeaturefeaturefeaturefeaturefeaturefeaturefeaturebugfeaturefeaturefeaturefeaturebugfeaturebugbugbugbugfeaturefeaturefeaturefeaturebugfeaturefeaturebugfeaturefeaturefeaturefeaturefeaturebugfeaturechorechorechorechorebugchorechorefeaturefeaturefeaturebugbugchorebugfeaturefeaturechorefeaturefeaturefeaturefeaturefeaturefeaturefeaturechorebugfeaturefeaturefeaturefeaturebugfeaturefixfeaturefeaturefeaturefeaturefeaturefeatureacceptanceacceptanceacceptanceacceptanceacceptanceacceptanceacceptancefeatureacceptanceacceptanceacceptanceacceptanceacceptanceacceptanceacceptanceacceptanceacceptanceacceptanceacceptanceacceptancefeatureacceptanceacceptanceacceptanceacceptanceacceptanceacceptanceacceptanceacceptanceacceptanceacceptanceacceptanceacceptancefeaturefeaturefeaturefeaturefeaturefeatureacceptanceacceptanceacceptanceacceptanceacceptanceacceptanceacceptanceacceptanceacceptanceacceptanceacceptancefeaturebugfeatureacceptanceacceptanceacceptanceacceptanceacceptanceacceptanceacceptanceacceptanceacceptanceacceptanceacceptanceacceptancebugbugbugfeatureacceptanceacceptanceacceptanceacceptanceacceptanceacceptanceacceptanceacceptanceacceptancefeatureacceptanceacceptanceacceptanceacceptanceacceptanceacceptanceacceptanceacceptanceacceptancebugfeatureacceptanceacceptanceacceptanceacceptanceacceptanceacceptanceacceptanceacceptancebugbugbugquestionfeaturefeaturechorechorequestioncheckcheckcheckcheckcheckcheckcheckcheckfeaturefeatureacceptanceacceptanceacceptanceacceptancefeaturefeaturefeaturebugchorequestionfeatureacceptanceacceptanceacceptanceacceptanceacceptanceacceptancebugquestionbugbugacceptanceacceptanceacceptanceacceptancechorefeaturebugquestionquestionfeaturefeaturefeaturequestionchorebugfeaturebugbugbugbugfeaturechorebugbugbugacceptanceacceptanceacceptanceacceptanceacceptancefeaturefeatureacceptanceacceptanceacceptanceacceptanceacceptanceacceptanceacceptanceacceptancefeaturefeaturefeaturefeaturefeaturefeaturefeaturefeaturefeaturefeaturefeaturefeaturefeatureacceptanceacceptanceacceptanceacceptanceacceptanceacceptanceacceptancefeatureacceptanceacceptanceacceptanceacceptanceacceptanceacceptanceacceptancefeaturefeaturefeatureacceptanceacceptanceacceptanceacceptanceacceptanceacceptancefeaturefeaturefeatureacceptanceacceptanceacceptanceacceptancefeaturefeaturefeaturefeaturefeaturefeaturefeaturefeaturequestionfeaturefeaturefeaturefeaturequestionfeaturefeaturefeaturefeatureacceptanceacceptanceacceptanceacceptanceacceptanceacceptanceacceptancefeatureacceptanceacceptanceacceptanceacceptancefeaturebugacceptanceacceptanceacceptanceacceptanceacceptancebugacceptanceacceptanceacceptanceacceptanceacceptanceacceptanceacceptanceacceptancebugfeaturefeatureacceptanceacceptanceacceptanceacceptanceacceptanceacceptanceacceptanceacceptancefeaturefeaturefeaturebugacceptanceacceptanceacceptanceacceptanceacceptanceacceptanceacceptanceacceptancebugfeaturefeaturefeaturefeaturefeaturefeaturefeaturefeaturefeature
Пульс Цен (дашборд клиента)
Аналитика лидогена My Vision для клиента: события, цепочки, атрибуция.
repo: localserver: cfru :3061, Next.js+Prisma+SQLitedocs: память puls-cen-*память: puls-cen-dashboard, puls-cen-sprint-features
готовS1 · Спринт 6 фич6/6
Цель: Фичи дашборда по запросу клиента
Контекст в цепочках
Sendsay интеграция
Входящие
✓ Раздел /inbound: воронка входящий→оплата, 4 типа обращений, фильтры (менеджер/регион/время/источник/результат/период/поиск), аналитика по дням недели и часам, дозвон-рейт, повторные, режим «Клиенты» с историей. Данные до 20 июля.
Сравнение месяцев
✓ PeriodCompare: сравнение периодов по произвольным датам (A vs B), метрики дропдауном, встроено на Обзор/События/Каналы/Баннеры/Регистранты/Входящие/Продажи. Старая /compare осталась.
Атрибуция first/last/linear
✓ Глобальная атрибуция first/last/linear (переключатель в сайдбаре, localStorage). Каналы/Рассылки(сервер)/Баннеры — устраняет переучёт оплат (сумма сохраняется, распределение по модели).
Демо-Продажи
✓ Конструктор /sales: фильтры (период/менеджер/регион/услуга/триггер/сценарий/стадия/поиск), разрезы, «после какого события берут в работу», «частое след.событие», воронка, скорость сделки, проваливание в путь клиента. ~72 демо-сделки (реального отчёта Тюльпана нет).
готовS2 · Метрика + Аналитика ИИ5/5
Цель: Раздел Метрики (счётчик 200476), детерминированная Аналитика ИИ, полный анализ страниц, обновление данных, кроны
Раздел «Аналитика ИИ»
✓ compiled-AI разбор месяца (/ai, без LLM): cohort-отклик на письма с контролем окна созревания (3/7/14 дн), интенсивность+глубина событий за одинаковый отрезок, метрика ключевых страниц, источники по страницам с драйвером просадки. Вывод: отклик на письма не упал, проблема в притоке.
Раздел «Метрика» (счётчик 200476)
✓ Яндекс.Метрика вживую: динамика/источники/страницы (фильтр по URL-метке)/цели. Токен взят из ПЦ Директ (общий, слать последовательно). Метрика обновляется сама, крон не нужен.
Подраздел «Наши страницы» — полный анализ
✓ 6 платформенных страниц: месяц vs прошлый (просмотры/посетители/отказы + Δ), тренд по 6 месяцам с переключателем метрики и спарклайнами, источники по каждой странице (визиты по каналам cur vs prev), топ-25 статей блога по заходам. МОРС=онлайн-магазин сервисов.
Заливка июльских отчётов до 31.07
✓ события/КЦ/звонки/регистранты за июль (папка «Отчеты ПЦ»). Дедуп КЦ на чтении по actionId, ФРАНШ отфильтрован. Аналитика ИИ теперь на полном июле (partial=false).
Кроны: Sendsay + прогрев кэша
✓ Sendsay-выгрузка еженедельно (пятница 08:00 МСК, защита от обнуления при пустом ответе). Прогрев тяжёлой аналитики (страницы+ИИ) каждые 3ч + кэш 6ч → пользователю мгновенная выдача, пересчёт в фоне.
готовS3 · Правки дашборда (страны, разрез, дефолты)3/3
Цель: Регистранты: страна+переименование; дефолт текущий месяц везде; связки-разрез в Сравнении месяцев
Регистранты: клиент→регистрант + разрез «Страна»
✓ Переименование клиент→регистрант по всей странице. Новый разрез «Страна»: РФ/Казахстан отдельно, остальное → «Страны-импортёры» с раскрытием по странам (реальная страна из «Основного региона») + KPI «Стран-импортёров». Уточнён тултип «первое событие→конверсия».
Дефолт «текущий месяц» во всех разделах
✓ currentMonthRange/lastMonths в lib/format; useStickyFilters + Registrants/Inbound/Metrika/AI дефолтят на текущий месяц (жёстко, по решению заказчика). Демо-Продажи не трогали (данные апрельские).
Сравнение месяцев: связки (серии+разрез+поиск)
✓ Билдер серий как в Цепочках: поиск сущности, показатель, опциональный разрез (ЦУ/регион/источник/профильник; события — регион/ЦУ) раскладывает серию на линии по значениям (топ-8). computeSplit в compareCatalog. Проверено: 1 серия × разрез ЦУ → 5 линий.
готовS4 · S29 — режим «Платящие» (портфель ПП)28/37
Цель: Второй дашборд рядом с НК: переключатель режимов, заливка «Аналитики для продаж», обзор портфеля, разбор проработки, реестр сайтов
Разбор выгрузки «Аналитика для продаж» и сверка формул
✓ 100 строк / 98 клиентов, 60 колонок. Проверено: метка о проработке = количество товаров (%=метка/публикуемые, 100 из 100), масса=публикуемые+непубликуемые, динамика год/год сходится 52 из 52. Фасеты не сходятся с публикуемыми (12 из 100) — вопрос клиенту.
Модель данных и заливка портфеля
✓ PpSite (снимок), PpViews (просмотры по месяцам, накопительно — переживают смену колонок в новых файлах), ShowcaseDomain (под Метрику, пустая). Детект по шапке в общем ingestFile, повторная заливка месяца заменяет снимок. Миграция 20260821120000_pp_sites.
Переключатель дашбордов НК / Платящие
✓ Вверху сайдбара, режим из адреса (/pp*). В режиме платящих скрыты разделы лидогенерации и тумблеры сегмента/ЦУ/атрибуции.
Обзор портфеля платящих
✓ KPI (просмотры за месяц и год к году, размечено товаров, сайты с проработкой, масса, ЦД, трафик), график по 13 месяцам, блоки внимания: не проработаны / пакет заканчивается / проработаны без роста. Нулевые показатели не выводятся.
Раздел «Проработка» с эффектом по когортам
✓ Охват и корзины процента, динамика по месяцам, эффект «до/после метки» по месяцам простановки (база = среднее за 3 месяца до), медиана роста рядом со средним (декабрь: среднее +812%, медиана +67%), топы роста/падения/без отдачи, разрезы по ЦУ/менеджеру/региону/пакету/рубрике, ЦД на 1000 просмотров, выгрузка в Excel.
Реестр «Проработанные товары»
✓ Сортировка по любой колонке, фильтры (ЦУ, менеджер, регион, пакет, рубрика, поиск, есть/нет проработки), спарклайн по месяцам, ссылка в портал из гиперссылки файла, пагинация, выгрузка всей выборки в Excel (лимит 5000 строк с честным предупреждением).
Проверка на объёме и ускорение заливки
✓ Файл на 5000 строк: построчный upsert просмотров давал 65 000 запросов и дольше 5 минут → пакетная запись, стало 9 секунд. API: обзор 0,35 с холодный / 0,02 с из кэша, реестр 0,013 с.
Метрика по витринам клиентов
Проверено на живом API счётчика 200476: витрины клиентов на своих доменах видны (ym:pv:URLDomain работает), а страницы pulscen.ru/firms/<ид сайта> по 100 сайтам за 3 месяца дали ~95 просмотров — привязки по ид сайта нет. Нужен адрес витрины в выгрузке клиента; таблица ShowcaseDomain уже есть. Владелец попросит колонку у клиента.
Деньги по платящим (приходы за продления)
Выгрузка приходов по платящим будет позже — владелец обещал файл. Сейчас в базе 61 платёж, из 98 клиентов портфеля совпал 1: это первые оплаты НК, продлений нет. До файла денежные блоки не показываем.
Волна 2: качество карточек, трафик, карточка клиента, конструктор отчётов
Данные по фото/фасетам/группам уже заливаются в PpSite, экранов нет. Плюс сравнение снимков между выгрузками и режим платящих для событий/цепочек/звонков (в пуле добавить сегмент pp).
S29.1 Общие разделы в режиме ПП + правки фильтров
✓ Вкладка переименована в ПП. В пул событий добавлен сегмент pp (всё кроме НК): на проде НК 15 572 события / 7 124 клиента, ПП 13 321 / 3 679. Разделы «События» и «Цепочки» работают в ПП на этом пуле, подписи «лид» заменены на «клиент». «Сравнение месяцев» для ПП написано заново (НК-версия строится на РЕГИ, где платящих почти нет): месяц × показатель с разрезом по ЦУ/региону/пакету/менеджеру/событию, график, таблица, Excel; итог по клиентам — уникальные за период, а не сумма месяцев. Во все выпадающие списки добавлен поиск, значения не обрезаются, написание ЦУ нормализовано.
S29.2 Кликабельные разрезы в Событиях
✓ Блок «Разрезы» в разделе Событий (оба режима): вкладки ЦУ / менеджер / регион / пакет / событие / рубрика / статус сайта / критерий, колонки события, клиенты, приходы, доля; сортировка по любой колонке, клик по строке кладёт значение в фильтр раздела (и снимает повторным кликом). Деньги считаются по уникальным клиентам среза, чтобы не задваивать на событиях. Написание ЦУ нормализуется для группировки, а в фильтр уходят исходные написания — иначе клик по «Пульс Цен Пермь» не находил «Пульс цен Пермь» и обнулял выборку. Пункт меню «Обзор портфеля» переименован в «Обзор».
Выгрузка состава плана месяца по ЦУ для аналитика
✓ Эндпоинт /api/export/plan-clients (месяцы, ЦУ, сегмент) повторяет логику разреза «План месяца»: категории, КЦ из отчёта по действиям, ЦУ из РЕГИ → справочник городов → фолбэк. Отдан файл по СО (ЕК+ПМ) за июль и август: 317 строк клиент × категория × месяц, 190 компаний, листы «Клиенты по категориям», «Компании (свод)», «Сводка с колонкой как на экране», «Как считалось». Сверено с дашбордом: август сходится полностью, июль — кроме прайса (75 против 77).
ПП: подсказки, ид компаний, карточка по клику
✓ 1) Подсказки-вопросики переведены на портал в body с фиксированными координатами — в таблицах с прокруткой их срезал контейнер, текст не появлялся (починилось и в НК). 2) В реестре под названием видно ид клиента и ид сайта, в топах проработки — ид сайта. 3) Клик по компании в реестре, в топах проработки и в блоках внимания на обзоре открывает карточку: паспорт, товары, проработка с рубриками, просмотры по месяцам с год к году, отдача и трафик, группы, ссылка в портал. Нули в карточке не выводятся.
Разобраться со сдвигом месяца на границе (часовой пояс)
События хранятся с временем суток, а месяц на экране считается по локальному времени браузера (UTC+5). Из-за этого события последнего дня месяца после 19:00 попадают в следующий месяц: по июлю экран показывает «Просмотрел прайс лист» 341 (СО ЕК+ПМ 77), а по календарным датам 339 (75); в августе СК 72 против 71. Чинится переводом расчёта месяца на компоненты даты без часового пояса, но это изменит числа в разделах НК — согласовать с владельцем перед правкой.
Тарифы и непроработанные товары в ПП
✓ Запрос заказчицы. Тариф: фильтр в панели, колонка в реестре, строка в карточке, разрез «По тарифам» (Бизнес 18 сайтов / 223 030 непроработанных / 16 052 просмотра / ЦД 326, SEO PRO, Региональный кластер, Стандарт, Вся Россия, Всё включено, Старт). Непроработанные = публикуемые минус размеченные: плитка на обзоре, колонка в реестре и разрезах, строка в карточке, обе колонки в выгрузках Excel.
Движение по тарифам между выгрузками
Снимки портфеля копятся по месяцам (Report type=ppsites), но пока залит один — июль. Со второй выгрузкой сделать раздел: кто сменил тариф, в какую сторону, что стало с товарами и просмотрами. Для гипотезы про рост бюджета нужна ещё цена тарифа (отдельная задача).
Цена тарифа: нужен прайс или оплаты по действующим клиентам
В выгрузке «Аналитика для продаж» цены нет. В отчёте приходов 151 строка за май-август, из 98 клиентов портфеля совпали 2: там первые оплаты новых клиентов (102 строки), продлений действующих нет. Нужен один из двух источников: справочник «тариф → цена» или выгрузка оплат действующих клиентов (ид клиента, дата, сумма, тариф). Второй лучше: даст факт, средний чек и динамику бюджета.
Мини-аналитика по клиенту (как разбор Экополиса)
Разобран файл «сравнение для 98207662 Экополис»: 4 листа. У нас нет данных для трёх: 1) помесячная статистика ЛК (просмотры, посетители, просмотры телефона, эл. контактов, адреса, итого ЦД) — есть только просмотры проработанных товаров и одно число ЦД за прошлый месяц; проверено, что Метрика по домену витрины даёт другие числа (stroikzn.ru за май 2026: 6,3 тыс. против 12,4 тыс. в файле), то есть источник другой; 2) заказы в ЛК (ид, дата, тип, товар, рубрика, сумма, регион, урл первого захода, место оформления, устройство) — их нет совсем; 3) показатели рекламной кампании клиента (показы, клики, макроконверсии). Если выгрузки будут приходить файлами, страница собирается автоматически по всем клиентам. Отдельно: Экополиса нет в нашем срезе — нужен полный список вместо 100 строк.
Разобрать расхождение 1009 и 1154 в Плане месяца
✓ Потери нет, это три разные величины. 1154 — сумма фактов по семи категориям, где компания считается в каждой категории, куда попала: 647 уникальных компаний дали 1153 засчитанных попадания, переучёт 506 (2 категории у 192, 3 у 86, 4 у 39, 5 у 5, 6 у одной). 1009 — уникальные компании с любыми событиями за месяц, из них в категориях плана только 647, остальные 462 были в других событиях. Плюс 100 компаний есть только в отчёте КЦ и в пул событий не попадают (отсюда 49 в колонке «не определён»). Правки интерфейса готовы локально, НЕ выкачены по просьбе владельца: «Факт лидов» получил подпись «уникальных компаний 647» и честный тултип про сумму, в разрезе по ЦУ строка переименована в «Уникальных компаний» и добавлена строка «Из них в категориях плана» (МСК 169, СО ЕК+ПМ 113, СО РОССИЯ 316, не определён 49, всего 647).
Выкатить правки подписей в Плане месяца
Собрано и проверено локально на копии продовой базы. Ждёт отмашки владельца: просил не заливать, пока в разделе ПП идут правки.
ЦУ для клиентов колл-центра: убрать «не определён»
✓ Замечание владельца: у действий колл-центра регион есть, а в расчёт ЦУ не попадал. Проверено: у всех 1021 августовской записи КЦ регион заполнен, все 478 клиентов с регионом, справочник городов на 269 строк. Причина: регион брался только из событий месяца, у клиентов без событий его не было. Теперь getKcActions отдаёт регион, План месяца использует его как запасной источник. Колонка «не определён» исчезла: 49 клиентов КЦ разошлись по своим ЦУ (МСК 106, СО ЕК+ПМ 90, СО РОССИЯ 221 в строке КЦ АКТИВНОСТИ). Заодно клиенты, которых касался только колл-центр, вошли в число уникальных компаний: 1109 вместо 1009 (МСК 295, СО ЕК+ПМ 234, СО РОССИЯ 580) — иначе строка «из них в категориях плана» могла превысить итог. Собрано локально на копии продовой базы, на прод НЕ выкачено.
Приходы по ЦУ: Екатеринбург (НК) больше не отдельной строкой
✓ Вопрос владельца. В отчёте приходов ЦУ записан офисом менеджера («Пульс Цен Екатеринбург (НК)»), а свод работает в системе МСК / СО (ЕК+ПМ) / СО РОССИЯ. В normalizePayCu были правила только для Москвы, Новосибирска и Сетевого отдела, Екатеринбург и Казань падали как есть. Теперь значения, не сведённые к своду, доводятся по справочнику городов клиента. Итог: СО (ЕК+ПМ) 819 880 руб и 10 клиентов вместо 704 880 и 9 плюс отдельная строка на 115 000; МСК и СО РОССИЯ не изменились, общий приход те же 1 941 445. Попутно выяснилось: у ЭНЕРГОСЕРВИС (554649) и Ди-трейд (582660) нет записей в РЕГИ, их ЦУ берётся только из приходов. Собрано локально, на прод не выкачено.
Единое правило ЦУ на весь дашборд
✓ Главная причина «где фильтрует, где нет»: ЦУ считался только по карте из РЕГИ, а она покрывает не всех. Вынес правило в lib/cu.ts (реги → город по справочнику → страны СНГ в МСК → остальное в СО РОССИЯ) и подключил везде: события, обзор, входящие, план, регистранты, сравнение, источники регистрации, звонки, приходы. Регион строки передаётся в фильтр, а для данных без региона собирается карта клиент→регион из пула событий. Список ЦУ в сайдбаре теперь система свода, а не «что попалось в реги».
Фильтр ЦУ в приходах, источниках регистрации и звонках
✓ Приходы игнорировали выбранный ЦУ целиком — теперь режут KPI, разрез и топ клиентов (МСК: 560 600 руб, 4 клиента). Источники регистрации: было «370 из 600» при любом ЦУ, стало «107 из 174» для МСК. Звонки реагировали только деньгами, теперь фильтруется и сам список. Помесячная строка приходов помечена «по всем ЦУ» — её сервер отдаёт без разбивки по клиентам.
Разрезы: центр учёта отдельно от офиса менеджера
✓ Вопрос владельца «почему при выборе ЦУ показываются другие ЦУ». В разрезе стоял ЦУ менеджера из строки события (Сетевой отдел, Беларусь и прочие), а фильтр работает по своду. Добавлена вкладка «Центр учёта» (по умолчанию, три значения как в сайдбаре, клиенты без реги раскиданы по городам), старая переименована в «Офис менеджера».
Карточка клиента: одно боковое окно везде
✓ Было: часть разделов открывала окно, приходы уводили на отдельную страницу, а платящий клиент выдавал «не найден в пуле НК». Добавлен эндпоинт /api/client (полный пул + приходы) и общий компонент ClientDrawerById: открывается везде боковым окном, работает для клиентов без событий (показывает деньги из оплат). Страница /client/[id] переведена на тот же источник.
Статус счёта и деньги в таблице событий
✓ Счёт показывался «ждёт» рядом с «оплачено 167 400» — статус брался из событий, а деньги из приходов. Теперь если приходов клиента хватает на счёт, он «оплачен» (проверено на Техмаш). В таблицу событий добавлены колонки «Счёт» и «Приходы» по клиенту.
Фильтры прилипают к верху экрана
✓ В Событиях панель фильтров стала sticky. Сначала не липла: контейнер страницы имел overflow-x-hidden, который делает элемент прокручиваемым и ломает sticky — заменено на overflow-x-clip.
Деньги считаются за выбранный период, а не за всё время
✓ Корень жалоб «июльские суммы в августе». payMap.money отдавал приходы клиента за всю историю, и это показывалось рядом с выборкой месяца: у Капустиной 680 000 за август, в раскладке лидов всплывал Глобал Трейдинг (клиент июля), в Событиях приходы 474 100 против 560 600 в Обзоре. Теперь сервер отдаёт учтённые платежи с датами, у провайдера появился moneyIn(клиент, с, по) и хук useMoney(период). Переведены Обзор, События, Каналы, Рассылки, Входящие, Регистранты, Сравнение периодов (там деньги ложатся в тот период, когда пришли). В карточке клиента осознанно осталась сумма за всё время — подписано «приходы, всего».
Фильтр «ЦУ» в панели переименован в «Офис менеджера»
✓ В панели фильтров это ЦУ из строки события (Сетевой отдел, Беларусь, офисы НК), а не свод из сайдбара — владелец справедливо путался, почему при выбранном МСК в списке много других ЦУ. Название разведено, как и во вкладках разрезов.
Раздел «Продажи»: крупная плашка про придуманные данные
✓ Аудит фильтров показал: раздел не реагирует ни на ЦУ, ни на сегмент, потому что работает на выдуманных сделках (менеджеры Волкова, Иванов и прочие). Мелкий бейдж «Демо-данные» терялся. Добавлена плашка в потоке страницы: числа брать в отчёты нельзя, выгрузки по продажам нет.
НК: убрать из приходов деньги действующих клиентов
✓ Директор по НК заметил Энергосервис (554649) в приходах НК — проверено, обе его оплаты за август это «Доплата» (60 000 и 55 000), то есть ПП. Теперь блок называется «Приходы новых клиентов» и показывает только тех, у кого ПЕРВАЯ оплата за всю историю отчёта попала в период: доплаты, повышения пакета и оплаты ранее плативших исключены. По августу это отсекло 429 845 руб у 6 компаний, включая АВИТЕКС (первая оплата 29.06) и ДЕКСИС (31.07) — их владелец тоже назвал ПП. Стало 1 511 600 руб и 16 НК вместо 1 941 445 и 18. Исключённая сумма показана строкой с именами, чтобы сходилось с полным отчётом.
Разрезы: убрана вкладка офиса менеджера
✓ Владелец дважды указал, что в разрезе ЦУ должно быть три значения. Вкладка «Офис менеджера» (Сетевой отдел, Беларусь, офисы НК) из разрезов убрана совсем, остался только «Центр учёта» — три строки как в фильтре сайдбара. Офис по-прежнему доступен как фильтр панели.
Аудит фильтров по всем страницам и блокам
Прогнано автоматом: на Обзоре и в Событиях каждый из семи фильтров панели (события, офис менеджера, регионы, пакеты, менеджеры, статусы, критерии) реагирует; фильтр ЦУ проверен на 11 страницах — везде режет, кроме Продаж (там придуманные данные, помечено плашкой). НЕ проверено: каждый блок внутри страниц по отдельности, фильтры дат на всех страницах, взаимодействие фильтров между собой, сходимость чисел между разделами после перевода денег на период. Продолжить прогон и свести таблицу «страница × фильтр × блок».
Правило НК: вернули учёт по разметке строк оплаты
✓ Владелец уточнил: АВИТЕКС это НК и раньше считали правильно — повторная «Первая оплата» (новый сайт или регион у знакомой компании) остаётся новым клиентом. Убрал введённое было правило «первая оплата за всю историю». Сейчас в НК попадают строки «Первая оплата» и «Доп. регион», исключаются только доплаты и повышения пакета: 1 690 170 руб и 18 НК за август, отсечено 251 275 руб у 4 компаний (Энергосервис, ЗСК Бетон, Техимпульс, Снабэкс-ДВ).
Липкие фильтры на всех страницах
✓ Раньше липла только панель в Событиях. Sticky перенесён в сам компонент панели фильтров, поэтому работает на обзоре, событиях, каналах, баннерах, рассылках и цепочках. Отдельно сделаны свои панели: регистранты (проверено на проде — прилипает, top 0), входящие и все разделы ПП.
готовS5 · S30 — Приходы: ЦУ, сверка, A/B-тесты, метрики Обзора35/36
Цель: ЦУ приходов из файла, сверка с ручной чисткой, A/B по переходам, конверсия+деньги в Обзоре
A/B-тесты: метрика «Переходы» + тест мобильных прайс-табов
✓ Добавил метрику «Переходы (просмотры)». Завёл тест «Прайс мобайл — переходы по табам»: эталон июль, устройство mobile, линия на каждый таб + сумма. Считает и рендерит на бою.
Приходы: ЦУ берём из файла приходов (фикс «не определён»)
✓ В файле приходов ЦУ есть у 100% строк, а брали из РЕГИ, где НК не зарегистрированы → «не определён». Теперь читаем ЦУ прямо из прихода, нормализация МСК/СО(ЕК+ПМ)/СО РОССИЯ/Новосибирск. «Не определён»=0, совпало с ручной разбивкой аналитика (5/7/24).
Обзор: конверсия в НК + деньги в блоке «Лиды по числу событий»
✓ На каждой корзине (1/2/3/4+ событий) показываю сколько лидов стали НК (+% конверсии) и сколько денег принесли. В раскрытии — строка-итог и деньги по компаниям с бейджем нк. Инсайт: 3 события конвертят лучше всего (7%).
Сверка приходов с ручной чисткой аналитика (Книга1, июль)
✓ 34/36 клиентов копейка в копейку. Разрыв −30 000 = клиент 362935 (система 30к из 29900+100, аналитик 60к). Плюс пара 620351/620597 — разные записи по 108 400, взаимно гасятся. Строка «Общий итог» в файле задваивала сумму — исключил.
Аналитика ИИ: свежий пересчёт за август
✓ 6 понятных инсайтов, partial-aware (до 21.08), сравнение на равном окне 1–21. Рассылки, активность лидов, сильные действия, переходы, ключевые страницы, источники просадки.
Свести приходы к 0 по исходной полной выгрузке (−30к, клиент 362935)
Нужна исходная ПОЛНАЯ выгрузка приходов (сырая, со всеми строками и датами), из которой аналитик чистил июль. Сверить построчно: реально было 60 000 у 362935 или задвоение.
Решить, куда относить ЦУ «Новосибирск (НК)»
В таксономии РЕГИ только МСК/СО(ЕК+ПМ)/СО РОССИЯ. Новосибирск (10 приходов) сейчас отдельной строкой. Спросить у клиента: отдельно или влить в один из трёх.
✓ Новосибирск переехал в СО РОССИЯ — применено в приходах и регах.
Реги+События: раскидать все по справочнику город→ЦУ (фикс #REF!)
✓ 3978 регов висели с cu=#REF! (сломанная формула мастера) — справочник по городу к ним не применялся, т.к. #REF! непустой. Теперь #REF!/#Н/Д трактуем как пусто → включается cityCu[город]. Бэкфилл: 3892 из 3983 разложены (СО РОССИЯ 1822/МСК 1337/СО(ЕК+ПМ) 733), #REF!=0. Карта клиент→ЦУ для событий выросла ~1115→4701. 92 зарубежных (Астана, Турция…) без ЦУ — их нет в справочнике.
Перезалить справочник город→ЦУ + обогатить регов (companies_report 21.08)
✓ Справочник = «Правила передачи клиентов + города.xlsx», лист «Города и ЦУ» (269): Ощепкова→СО РОССИЯ, Бойдова→СО(ЕК+ПМ), Москва→МСК. Перезалит. Плюс залит 21.08.2026_companies_report.csv (499 регов) — cu выведен из региона по справочнику.
UI: проценты конверсии в карточках корзин (точка ниже, цифры ближе)
✓ В блоке «Лиды по числу событий» на строке «в НК» точку опустил к базовой линии и сжал отступы: было «6 · 1%» по центру → стало «6·1%» с точкой внизу.
Правило ЦУ для непокрытых: зарубеж→СО РОССИЯ, 3 СНГ→МСК
✓ Фолбэк fallbackCu: всё, чего нет в справочнике город→ЦУ → СО РОССИЯ, КРОМЕ Азербайджана/Кыргызстана/Узбекистана → МСК (уже и так в справочнике). Русские города вне справочника (Королёв, Берёзовский, Новочебоксарск) → СО РОССИЯ. Бэкфилл 92 непокрытых рега, без ЦУ=0. Справочник = «Правила передачи клиентов + города», лист «Города и ЦУ».
План месяца: вкладка «По ЦУ» (сколько и каких лидов по ЦУ)
✓ Табы «По категориям»/«По ЦУ». Матрица категория×ЦУ (МСК/СО(ЕК+ПМ)/СО РОССИЯ) + строка «Уникальных лидов» + Всего, группировка Горячие/Тёплые. Клиент считается один раз в категории.
События раскидываем по ЦУ по региону события (справочник)
✓ События клиентов без рега теперь получают ЦУ по своему региону через справочник город→ЦУ (fallback тем же правилом). cityCu проброшен на клиент через /api/regi + CuProvider. «Не определён» в разрезе плана упал с 354 до 0 по пулу. ФРАНШ (Беларусь) свёрнут в СО РОССИЯ. Остаток: 35 КЦ-активности из отчёта действий без региона — привязать не по чему.
Загрузка: авто-детект кодировки CSV (UTF-8/cp1251)
✓ Новые выгрузки ПЦ в UTF-8, старые cp1251. Парсеры жёстко читали cp1251 → кракозябры в заголовках, файл приходов не распознавался. Добавил lib/xlsxRead.ts (pickCodepage по валидности UTF-8) и завёл во все 5 CSV-читалок (reports/payments/regi/ops/pp).
Загрузка приходов: даты ММ.ДД наоборот + двойной счёт
✓ xlsx угадывал даты CSV по US-раскладке ММ.ДД: 07.08(7авг)→8июля, 12.08→8дек (ломалось при дне ≤12). 12 августовских платежей улетали в чужие месяцы, дедуп не ловил (дата другая) → задвоение. Фикс: читаю даты как текст (raw:true), parseDate по дд.мм.гггг. Откатил битый отчёт, перезалил. Август=1 941 445 ₽ (=Итого файла), месяцы только V–VIII.
Обогащение НК: события/реги/КЦ/приходы на 28.08
✓ Залито из папки Отчет ПЦ: события +639 (до 28.08), companies 670 (ЦУ по справочнику), КЦ +224, приходы (полный август). ПП-файла (Аналитика для продаж) в папке не было — ждём отдельно.
ПП: поиск по клиенту (е/ё/э, токены)
✓ Причина: в базе «НПО Протэкт» (э), ввод «Протект» (е) не совпадал; поиск был однопроходный includes. Нормализация ё/э→е + пунктуация→пробел + AND по словам в filterSites (общий для всех ПП-экранов). «НПО Протект» теперь находит.
ПП Обзор: месяц-фильтр + кликабельный график + Excel
✓ Значение над КАЖДЫМ столбцом (июнь больше не «непонятно»), клик по столбцу выбирает месяц, плитка «Просмотры за <месяц>» + YoY по выбранному месяцу. Селектор месяца в фильтрах. Кнопка Excel на Обзоре (была только на Проработке/Реестре).
ПП карточка клиента: паспорт + подписи + целевые-заглушка
✓ Паспорт: ЦУ менеджера/менеджер/тариф/пакет/ид клиента+сайта + слот «Домен витрины: уточняется». «Отдача и трафик» — подпись периода и источника. Новый блок «Целевые действия»: телефон/почта/адрес как «появится позже» (данных пока нет) + итог за прошлый месяц.
ПП ссылки 403: разобрал
✓ processedUrl корректный и полный (297 симв.), ведёт на портал pulscen.ru/firms/{ид}/predl/binds?filters[...]. 403 даёт WAF/SmartCaptcha портала на тяжёлый bracket-запрос, не наша ошибка и не авторизация. Решить с владельцем: оставить или заменить на простую ссылку pulscen.ru/firms/{ид}.
ПП: залил статистику ЦД + переходы (помесячно по клиенту)
✓ Две новые выгрузки: «Статистика ЦД» (телефон/эл.контакты/адрес/итого, 58001 строк) и «Статистика переходы» (просмотры/посетители/переход на ИМ, 60921). Модели PpActivity/PpTraffic (миграция pp_stats), авто-детект в загрузках. Ключ «Компания» = ид САЙТА (совпал у 4801/4958), цепляю по siteId. Новая Аналитика тоже залита — портфель вырос 100→4958 сайтов.
ПП карточка: целевые в разрезе + трафик помесячно (реальные данные)
✓ В дровере блоки «Целевые действия» (просмотры телефона/почты/адреса + итого, диаграмма по месяцам) и «Трафик и переходы» (просмотры/посетители/переход на ИМ + диаграмма посетителей по месяцам). Заглушки «появится позже» заменены реальными данными из выгрузок ЦД/переходов. Директорский блок 3 закрыт.
Excel-выгрузки клиент×события (событ/сравн/цепочки/входящие/рассылки)
✓ Общий движок lib/clientExport.ts: матрица клиент×события (ид клиента/сайта, дата рег, регион, ЦУ, пакет + колонка на каждый тип события со счётчиком). Кнопка Excel по текущему фильтру на: События, Сравнение месяцев, Цепочки (по совпавшим с цепочкой), Входящие (матрица типов обращений), Рассылки.
Sendsay: выгрузка компаний по рассылке (0/1)
✓ В карточке рассылки Excel: ид клиента, клиент, ЦУ + 0/1 по Получил/Открыл/Перешёл/Событие/Звонок/Счёт/Оплата + сырые счётчики.
Кликабельные KPI-блоки на Рассылках → фильтр списка
✓ Клик по плитке (Действие после / Дошли до горячих / Приходы) фильтрует список клиентов ниже, плитка подсвечивается, повторный клик снимает.
События: КЦ активный/потенциальный полный охват (как в Плане месяца)
✓ Блок «КЦ — полный охват» из отчёта по действиям (не ~10% из событий). КЦ активный — один свод (Морс, СК, загрузки внутри). Уник. клиенты за период фильтра.
Страница «Отвалы» (база РК) + ожил + Excel
✓ Новая модель Churn + ингест (миграция churn), авто-детект. Залито 16563. Страница /churn: фильтры (регион/пакет/ЦУ/ожил/поиск), метка «ожил» (события за 30 дней), KPI, Excel. Даты отвала в файле нет — фильтр по дате не строил.
Каналы/Баннеры: Страница продавца→Баннеры + контексты баннеров
✓ classifyChannel: «Страница продавца» перенесена из Рассылок в Баннеры; добавлены контексты Слайдер/Небоскрёб/Центральный/Транспарант/баннер_ЛК → Баннер.
Правки: убрал Офис менеджера, КЦ в пул, Отвалы поп-ап+фильтры, Цепочки вёрстка
✓ 1) Фильтр «Офис менеджера» убран везде (дубль ЦУ). 2) КЦ активный/потенциальный из отчёта по действиям подмешаны в ПУЛ событий (НК-режим): отражаются во ВСЕХ цифрах (строки 16023→19722, лиды, воронка, клиенты, выгрузка), отдельный блок убран. КЦ активный — свод. 3) Отвалы: клик по компании = поп-ап (не новое окно), + фильтры «Ожил с/по» (дата последнего события) и «Ожил с событием». 4) Починил съехавшую вёрстку Цепочек (мой Excel-блок).
Каналы: колонка «Контекст» + фильтр по контексту
✓ В таблице Клиенты добавлена колонка «Контекст» (контексты «Перехода с рассылки» клиента), вверху — селектор фильтра по контексту. Колонка опциональная в общей ClientsTable (contextOf), другие страницы не задеты.
Звонки: переделал под свод (Результаты + Возражения + фильтры)
✓ Фильтр по датам и событию. «Результаты звонков»: Отработано=сумма; Счета/КП[Подготовка КП+Отправил КП+Встреча]/Оплаты/В работе[Повторный звонок+Принимает решение]/Да-но-не-сейчас/Откреплены/Недозвоны, % от отработанных. «Основные возражения» рядом (из Текст действия/Комментарий, последний контакт после события; кол-во клиентов = по событию минус недозвоны/оплаты/счета). Менеджеры перенёс вниз. Проверено на августе: Отработано 43 = сумма, возражения 29.
Цепочки: шаг «Любой» + считать только события до оплаты
✓ Добавлен шаг «Любой» (матчит любое событие, финальный шаг любой). Тумблер «только события до оплаты» (по комменту Ксении): считаем НК, у кого события цепочки были ДО первой оплаты, не уже-платящих. Счёт/оплата после прохождения цепочки — уже было. Вёрстку починил.
Продажи: реальные данные вместо демо
✓ Заменил демо на реальную страницу из отчёта по приходам + пула событий: KPI (приходы 10.76М, НК 99, средний чек, клиентов оплатили), приходы по месяцам, по менеджерам (приходы/сделки/НК), топ клиентов (кликабельны в карточку), Excel. Демо-поля (сценарий/услуга был-стал) не мапятся — убрал.
Звонки: все блоки скоуплены на событие + список лидов + Лиды(не Клиенты)
✓ Правки: верхние блоки (звонков/дозвон/деньги) теперь считаются по клиентам выбранного события (было — только по дате, не менялись). «Клиентов»→«Лидов». Добавил таблицу «Лиды выборки»: сами клиенты с итогом обзвона (звонков/дозвон/итог-бейдж/возражение/посл./приход), клик — карточка. Всё через единый computeCallsPage.
Продажи: фильтр периода + путь к продаже + с чего продажи
✓ Добавил фильтр по датам (приходы за период). KPI: Событий до продажи (3.1 ср.), Звонков до продажи (0.5 ср.) — по НК до первой оплаты. Блок «С чего были продажи» — последнее событие НК перед оплатой (Прайс 42%, Переход с рассылки 13%…). База пути 31 (НК с датой оплаты в счетах).
Звонки/Цепочки/Возражения: правки по фидбэку маркетолога
✓ Звонки: «Отработано» считалось только строго ПОСЛЕ события → 43 из 321. Переделал на любой контакт за выбранный период (лида ведут и до перехода) → 164 из 321 (51%). Тултипы/подзаголовок «после события»→«за период». Добавил 6 возражений Ксении (платное размещение/дорого/нет бюджета/заявок много/закрываются/другие каналы), поставил первыми. Блок «Отработано» перенёс сразу за «Лиды». Цепочки «Счёт 30 млн» — это была недедуплицированная колонка (один счёт лежит на 13 строках × = 17,4 млн у клиента 430847); дедуп по номеру счёта уже на бою, макс по всем 1,34 млн. Всё задеплоено.
В РАБОТЕS6 · S31 — Дашборд продавца12/13
Цель: Вариант ПП под продавцов: выбор себя, блоки Пакет заканчивается/Не проработаны/Динамика, разворот списков, отдельные страницы с фильтрами+Excel, правки поп-апа, Метрика по домену, Excel-отчёт по клиенту
A. Каркас: Обзор продавца
Пункт в меню ПП + /pp/seller (форк PpOverviewClient). Обязательный селектор «Я — продавец» (фильтр manager). Нижние блоки: 1)Пакет заканчивается 2)Не проработаны 3)Динамика (микс роста и падения). Снять cap .slice(0,10) ppCalc.ts:331/361/370 → «показать всех».
✓ Задеплоено. Новый раздел /pp/seller «Дашборд продавца» (форк PpOverviewClient). Наверху обязательный селектор «Выбери себя», всё скоуплено на менеджера (hideManager в PpFiltersBar). Нижние блоки в порядке: 1)Пакет заканчивается 2)Не проработаны 3)Динамика (проработанные и с ростом, и с падением, по |yoy|). Списки с «Показать всех (N)» — cap снят через flag full=1 в ppOverview. Проверено на API: продавец=77 сайтов, динамика=64. Excel-выгрузка обзора продавца (Пакет/Не проработаны/Динамика/по месяцам) с ид сайта.
B. Отдельные страницы: Не проработаны / Пакет заканчивается / Динамика
Страница на блок. Все фильтры + диапазон дат + Excel (ид клиента, ид сайта, инфо).
✓ Задеплоено. Три отдельные страницы в режиме Продавец (левое меню): /seller/package-ending, /seller/no-processing, /seller/dynamics. На каждой: селектор «выбери себя» (обязателен), все фильтры ПП (hideManager), полная таблица (не 10, а все) с кликом в карточку, выгрузка Excel с Ид клиента + Ид сайта + инфо. На «Пакет заканчивается» — фильтр по диапазону дат окончания пакета (заменяет окно 60 дней); проверено: окт 2026 = 293 пакета. Даты на «Не проработано/Динамика» пока нет — в снимке для них нет пригодного поля даты (можно добавить по дате проработки для Динамики, если нужно).
C. Правки поп-апа карточки клиента
Размечено→Проработанных; Дата метки→Дата проработки. График проработанных вниз перед Группами. Трафик Яндекс/Гугл всегда. Целевые: разноцветный stacked, клик по месяцу→цифры месяца.
✓ Задеплоено. Поп-ап: «Размечено»→«Проработано товаров», «Дата метки»→«Дата проработки», график проработанных перенесён вниз перед «Группами», структура трафика Яндекс/Гугл показывается всегда (была fallback), целевые — разноцветный stacked-график по типам (телефон/почта/адрес) с выбором месяца кликом. Плюс по правке владельца: на Обзоре ПП и Продавца общий блок из 3 постоянных столбцов — 1)Пакет заканчивается (+ услуга/чек/счёт) 2)Не проработано товаров 3)Динамика по проработанным (и рост, и падение). Блок «Пакет заканчивается» пропадал из-за застрявшего в localStorage фильтра manager — теперь столбцы всегда видны. Чек=приходы (по clientId), счёт=invoiceSum из событий: из 550 пакет-на-исходе счёт есть у 67, чек у 2 (приходы NK-ориентированы).
D1. Excel-отчёт по клиенту (exceljs)
exceljs: таблицы + графики картинками. Не зависит от домена.
✓ Задеплоено. Кнопка «Выгрузить в Excel» в карточке клиента → /api/pp/client-report на exceljs. Книга 4 листа: Карточка (паспорт+товары+проработка+трафик, стилизовано), Целевые по месяцам, Просмотры по месяцам, Трафик по месяцам — со столбиками в ячейке (нативные data-bars Excel). Проверено на Айскул Групп: валидный xlsx, данные на месте.
D2. Метрика по домену клиента в карточке
E. Вкладка «Пакет заканчивается»: счета и пакет
Правки со встречи по дашборду Платящих 08.09.2026 (задача от Наташи Блохиной). Данные брались из уже загруженных событий и выгрузки «Аналитика для продаж», новых файлов от клиента не потребовалось. Критерии: docs/ACCEPTANCE-S31.md, проверки scripts/check-s31e.mjs и scripts/check-s31e-pkg.mjs.
✓ Выкачено на прод 10.09.2026 до встречи в 15:30: сборка, pm2 restart, страницы 200, живой API отдаёт pkg, prevInvoice, prevInvoiceDate, invoiceDue, invoiceOpen
E1. Пакет виден рядом с услугой
✓ 99 сайтов с окончанием пакета, у 99 заполнен пакет, у 81 обе колонки и они разные: «Моттекс: услуга Стандарт, пакет Платина». На проде пакет у всех 4817 строк
E2. Дата счёта отдельной колонкой
✓ колонка была и осталась, invoiceDate
E3. Прошлый счёт с датой, не дубль текущего
✓ invoicesByClient сводит счета по номеру и берёт два последних. Проверка: 1183 клиента со счетами, у 46 есть прошлый, совпадений по номеру с текущим ноль. На проде 188 строк с прошлым счётом
E4. Пометка «не оплачен» с остатком
✓ invoiceDue и invoiceOpen. Проверка: 405 клиентов с неоплаченным, признак сходится с разницей суммы и оплаты везде. На проде 332 строки. Пример: БВБ-Альянс, счёт 125900 от 09.06 не оплачен целиком
E5. Фильтр по оплате: любой, не оплачен, оплачен, без счёта
✓ чипсы в AttentionBlocks, клиент без счёта в «оплачен» и «не оплачен» не попадает
E6. Пакет, прошлый счёт и признак оплаты в выгрузке Excel
✓ колонки на обеих выгрузках: страница продавца и обзор продавца
E7. Клиент без счетов не ломает таблицу
✓ money() отдаёт прочерк на нуле, фильтры требуют непустой счёт
В РАБОТЕS7 · S32 — Ядро данных: склад → чистые таблицы → переменные13/31
Цель: Любая цифра дашборда = одна именованная переменная, посчитанная в одном месте из всех загруженных файлов. Файл частью месяца ничего не ломает, перезалить старый файл безопасно, любую цифру можно раскрыть до исходника. План: docs/CORE-DATA-PLAN.md
↑ Э1 · Склад файлов
RawFile (sha256, тип, период) + RawRow (строка как JSON) + файл на диске /opt/pulse-analytics/store. Перезалить тот же файл = «уже есть». Все текущие файлы из Downloads/Отчет ПЦ и с сервера заливаются в склад. Существующие таблицы не трогаем. Критерии: docs/CORE-DATA-PLAN.md §6 п.2, 7.
✓ Склад файлов на проде: RawFile/RawRow + store/<sha256>.<ext>, 74 файла, 112 867 строк. ОТК круг 1: 7 подтверждённых находок закрыты (csv как есть через raw, файл из дублей не падает, удалённый отчёт перезаливается, строгая привязка по имени+тип+строки, гонка по sha256, русские ошибки, склад→разбор→откат). Экзамены 11/11, регресс 4/4. Срезы в docs/SCOPE-CUTS-LOG.md.
1. Загрузка кладёт файл в склад: в ответе sha256 и число строк, в реестре файл с именем, типом, периодом, строками
tests/spec/s32-e1.mjs · прогон: PULSE_URL=http://80.90.184.203:3061 node tests/spec/s32-e1.mjs
✓ Экзамен зелёный на проде 11.09.2026: node tests/spec/s32-e1.mjs → «прошло 11 из 11, красных 0». Регресс ОТК tests/otk/s32-e1-regress.mjs 4/4.
2. Файл на диске совпадает байт в байт: скачанный из склада файл даёт тот же sha256
tests/spec/s32-e1.mjs · прогон: PULSE_URL=http://80.90.184.203:3061 node tests/spec/s32-e1.mjs
✓ Экзамен зелёный на проде 11.09.2026: node tests/spec/s32-e1.mjs → «прошло 11 из 11, красных 0». Регресс ОТК tests/otk/s32-e1-regress.mjs 4/4.
3. Каждая строка сохранена как есть: 3 строки, исходные названия колонок и значения
tests/spec/s32-e1.mjs · прогон: PULSE_URL=http://80.90.184.203:3061 node tests/spec/s32-e1.mjs
✓ Экзамен зелёный на проде 11.09.2026: node tests/spec/s32-e1.mjs → «прошло 11 из 11, красных 0». Регресс ОТК tests/otk/s32-e1-regress.mjs 4/4.
4. Повторная загрузка того же файла: «уже есть», второй файл не появляется, строки не меняются
tests/spec/s32-e1.mjs · прогон: PULSE_URL=http://80.90.184.203:3061 node tests/spec/s32-e1.mjs
✓ Экзамен зелёный на проде 11.09.2026: node tests/spec/s32-e1.mjs → «прошло 11 из 11, красных 0». Регресс ОТК tests/otk/s32-e1-regress.mjs 4/4.
5. Битый файл (не таблица) не попадает в склад: 400 с сообщением на русском, в реестре его нет
tests/spec/s32-e1.mjs · прогон: PULSE_URL=http://80.90.184.203:3061 node tests/spec/s32-e1.mjs
✓ Экзамен зелёный на проде 11.09.2026: node tests/spec/s32-e1.mjs → «прошло 11 из 11, красных 0». Регресс ОТК tests/otk/s32-e1-regress.mjs 4/4.
6. Файл только с заголовком (0 строк данных) не попадает в склад: 400, в реестре его нет
tests/spec/s32-e1.mjs · прогон: PULSE_URL=http://80.90.184.203:3061 node tests/spec/s32-e1.mjs
✓ Экзамен зелёный на проде 11.09.2026: node tests/spec/s32-e1.mjs → «прошло 11 из 11, красных 0». Регресс ОТК tests/otk/s32-e1-regress.mjs 4/4.
7. Реестр группируется по месяцу и типу; у загруженного файла есть тип и месяц
tests/spec/s32-e1.mjs · прогон: PULSE_URL=http://80.90.184.203:3061 node tests/spec/s32-e1.mjs
✓ Экзамен зелёный на проде 11.09.2026: node tests/spec/s32-e1.mjs → «прошло 11 из 11, красных 0». Регресс ОТК tests/otk/s32-e1-regress.mjs 4/4.
8. Старые отчёты без исходника помечены: число отчётов без ссылки на файл склада = число «исходник не сохранён»
tests/spec/s32-e1.mjs · прогон: PULSE_URL=http://80.90.184.203:3061 node tests/spec/s32-e1.mjs
✓ Экзамен зелёный на проде 11.09.2026: node tests/spec/s32-e1.mjs → «прошло 11 из 11, красных 0». Регресс ОТК tests/otk/s32-e1-regress.mjs 4/4.
9. Удаление файла только с подтверждением: без него 400 и файл на месте; с ним файл и строки исчезают
tests/spec/s32-e1.mjs · прогон: PULSE_URL=http://80.90.184.203:3061 node tests/spec/s32-e1.mjs
✓ Экзамен зелёный на проде 11.09.2026: node tests/spec/s32-e1.mjs → «прошло 11 из 11, красных 0». Регресс ОТК tests/otk/s32-e1-regress.mjs 4/4.
10. Загрузка «только в склад» не создаёт отчёт и не трогает данные страниц
tests/spec/s32-e1.mjs · прогон: PULSE_URL=http://80.90.184.203:3061 node tests/spec/s32-e1.mjs
✓ Экзамен зелёный на проде 11.09.2026: node tests/spec/s32-e1.mjs → «прошло 11 из 11, красных 0». Регресс ОТК tests/otk/s32-e1-regress.mjs 4/4.
11. Файл 6 МБ (приходы ПП, тысячи строк) заливается в склад быстрее 60 секунд
tests/spec/s32-e1.mjs · прогон: PULSE_URL=http://80.90.184.203:3061 node tests/spec/s32-e1.mjs
✓ Прогон на проде: файл 6 МБ «Отчет_по_приходам- ПП.xls» (4 280 строк) — экзамен 11 зелёный (< 60 с); заливка 76 файлов, 113 тыс. строк — до 13 с на файл; пересборка строк 74 файлов — 1 мин 45 с.
12. Руками: на «Загрузках» реестр по месяцам и типам, у старых отчётов «исходник не сохранён», перезалитый файл даёт «уже есть», цифры Обзора не меняются
Руками: открыть http://80.90.184.203:3061/uploads, проверить реестр склада; перезалить файл из папки Отчет ПЦ в Загрузках; сравнить цифры Обзора до и после
✓ Проверено в браузере 11.09.2026: склад на «Загрузках» не показывается (решение владельца — служебный слой, без реестра и удаления в интерфейсе), повтор файла даёт «этот файл уже загружали, данные не менялись»; доменные таблицы до/после склада совпадают (EventRow 31 008, KcAction 4 616, Payment 927 …).
↑ Э2 · Чистые таблицы: события, действия КЦ, приходы
Пересборка из склада по правилам из lib/reports.ts, lib/ops.ts, lib/payments.ts (переносятся один в один). Сверка с текущими таблицами за июль–сентябрь: таблица «было / стало» с объяснением каждого расхождения. Критерии §6 п.1, 5.
1. Пересборка «события» из склада: строк не меньше, чем на страницах, у каждой ссылка на файл, ключ уникален
tests/spec/s32-e2.mjs · прогон: PULSE_URL=http://80.90.184.203:3061 node tests/spec/s32-e2.mjs
2. Пересборка «действия КЦ»: одна строка на ид действия с самой поздней датой, у каждой ссылка на файл
tests/spec/s32-e2.mjs · прогон: PULSE_URL=http://80.90.184.203:3061 node tests/spec/s32-e2.mjs
3. Пересборка «приходы»: одна строка на приход, поток НК/ПП по белому списку ЦУ, «новый» только у первой оплаты и доп. региона
tests/spec/s32-e2.mjs · прогон: PULSE_URL=http://80.90.184.203:3061 node tests/spec/s32-e2.mjs
4. Заморозка наследия: у отчётов без файла появляется синтетический файл «наследие», отчётов трёх типов без исходника — ноль
tests/spec/s32-e2.mjs · прогон: PULSE_URL=http://80.90.184.203:3061 node tests/spec/s32-e2.mjs
5. Сверка «было / стало» за июль–сентябрь 2026: события, события НК, КЦ потенциальный/активность, приходы НК — до единицы; приходы ПП — не меньше
tests/spec/s32-e2.mjs · прогон: PULSE_URL=http://80.90.184.203:3061 node tests/spec/s32-e2.mjs
6. Частичный файл: 1–11 число (2 строки), потом 1–20 (те же 2 + ещё 2) → в чистых событиях ровно 4
tests/spec/s32-e2.mjs · прогон: PULSE_URL=http://80.90.184.203:3061 node tests/spec/s32-e2.mjs
7. Перезалил старый файл и пересобрал — счётчики чистых таблиц не изменились
tests/spec/s32-e2.mjs · прогон: PULSE_URL=http://80.90.184.203:3061 node tests/spec/s32-e2.mjs
8. Пересборка с нуля дважды подряд даёт те же счётчики и тот же отпечаток ключей по каждому домену
tests/spec/s32-e2.mjs · прогон: PULSE_URL=http://80.90.184.203:3061 node tests/spec/s32-e2.mjs
9. Любая чистая строка раскрывается до исходника: по ключу возвращается файл склада
tests/spec/s32-e2.mjs · прогон: PULSE_URL=http://80.90.184.203:3061 node tests/spec/s32-e2.mjs
10. Пересборка не меняет старые таблицы страниц: EventRow, KcAction, Payment те же
tests/spec/s32-e2.mjs · прогон: PULSE_URL=http://80.90.184.203:3061 node tests/spec/s32-e2.mjs
11. Полная пересборка трёх доменов укладывается в 5 минут
tests/spec/s32-e2.mjs · прогон: PULSE_URL=http://80.90.184.203:3061 node tests/spec/s32-e2.mjs
12. Руками: «Обзор» и «План месяца» показывают те же цифры, что до этапа; в интерфейсе ничего нового
Руками: открыть Обзор и План месяца до и после этапа, сравнить цифры за август и сентябрь
↑ Э2 · Чистые таблицы: звонки, регистранты, план, ПП
Накопительные (звонки) и снимки (регистранты по ид сайта, план по месяцу с версиями, ПП по месяцу снимка). Решения владельца §7 п.1–2 применены по дефолту.
↑ Э3 · Реестр переменных + API + компонент
core/metrics.ts (код, название, формула словами, измерения), MetricValue, /api/metrics, компонент <Metric code=…/> с тултипом «формула + файлы». Служебная страница реестра для аналитика. Критерии §6 п.3, 4.
↑ Э3 · Переключить План месяца, Обзор, Приходы
По одной странице: сверка старых и новых цифр за три месяца, расхождения объяснены, «ок» владельца, потом переключение. Критерий §6 п.3.
↑ Э4 · Журнал «было / стало» и кнопка «Пересчитать всё»
После загрузки на «Загрузках» виден журнал изменений переменных; порог — жёлтая плашка. Критерий §6 п.6.
↑ Э4 · Остальные страницы и уборка
Звонки, Регистранты, Цепочки, События, ПП, продавец на переменных. Старые расчёты из lib/ удалены, ARCHITECTURE.md переписан, SCOPE-CUTS-LOG дописан, ОТК.
готовS8 · S33 — Чат с ИИ по всем данным14/14
Цель: РОП спрашивает по-русски, числа считает код: каталог из 8 наборов данных, таблица, Excel, история чатов. Модель deepseek-v4.1-flash через OpenRouter.
Чат с ИИ в режиме НК
✓ Выкачен на прод 18.09.2026. Каталог lib/aiChat/catalog.ts — 8 наборов (регистранты, события, приходы, звонки, рассылки, план, КЦ, теги). ИИ только разбирает вопрос в JSON, все числа считает движок. Экзамены tests/spec/s33-ai-chat.mjs — 14/14 на боевом.
1. Раздел появился в сайдбаре НК
✓ Живой прод, пункт «Чат с ИИ», в режиме ПП скрыт
2. Вопрос по каждому набору данных даёт ответ
✓ Экзамен s33: проверены все 8 наборов
3. Несколько фильтров и разрезов в одном вопросе
✓ Экзамен s33, комбинированный запрос
4. Числа считает код, не текст модели
✓ Сверка с разделом «Приходы»: 2 259 820 ₽ за август сходится
5. Ответ = число, сводка и таблица с ИД
✓ Экзамен s33, в ответе rows с ид клиентов
6. Понимает русский период, ЦУ, рубрику
✓ Экзамен s33, «за август», ЦУ и рубрика разбираются
7. Кросс-связки, что уже есть в коде
✓ Экзамен s33, связка клиент→события→приходы
8. История чатов, можно продолжить старую
✓ Модели ChatSession/ChatMessage, живой прод
9. Без ключа не падает
✓ Экзамен s33: без ключа — понятное сообщение, не 500
10. Мусор от модели — ретрай строгим промптом
✓ Экзамен s33, не-JSON обрабатывается
11. Периметр v1 — только НК
✓ Наборы ПП не заведены, ждут автосинка ПП
Ключ OpenRouter и лимит расхода
✓ Ключ в /opt/pulse-analytics/.env, лимит $20/мес (около 1900 ₽). Модель deepseek/deepseek-v4.1-flash: v4-pro думал 73 с и разбирал хуже. cfru пускает к openrouter.ai только через прокси 72.56.85.41:8888.
Сборка ответа модели по байтам, а не по буквам
Размер куска в ответе HTTP считается в байтах, а русская буква весит два байта. Сборка по буквам рвала JSON. Локально не видно — там прямой запрос без прокси.
✓ Блокер: на проде чат не работал бы вовсе и жёг по 3 платных вызова на вопрос. Исправлено на буферах, экзамен tests/unit/dechunk.mjs — 2/2.
готовS9 · S34 — Глубокие сегменты: до 7 связок и словарь внутренних слов16/16
Цель: Подбор клиентов по многим условиям сразу («металлопрокат + 4 события за 2 месяца + прайс-лист + рассылка + не взяты в работу + есть товар»), с воронкой по условиям.
Сегменты клиентов: несколько независимых условий и воронка
✓ lib/aiChat/segment.ts + clientIndex.ts: указатель на 29 709 клиентов из 8 источников собирается за 0,8 с. Экзамены tests/spec/s34-segments.mjs — 17/17.
1. Много условий сразу
✓ Экзамен s34: сегмент из 6 условий отрабатывает
2. Воронка по условиям — всегда
✓ Экзамен s34: в ответе всегда есть шаги воронки
3. Связка по номеру клиента и по сайту
✓ Экзамен s34: мостик сайт→клиент, дублей нет
4. Словарь внутренних слов
✓ Экзамен s34: «металлопрокат» берёт всю группу рубрик
5. Незнакомое значение — честно
✓ Экзамен s34: значения нет в данных — так и сказано
6. Ни одного технического слова наружу
✓ Проверено глазами на живых ответах
7. Время между событиями
✓ Экзамен s34: считается по дате и времени звонка вместе
8. Числа считает код
✓ Экзамен s34: сверка с прямым подсчётом по базе
9. Список и выгрузка по сегменту
✓ Экзамен s34 + tests/unit/export-query-kind.mjs
10. Отвалы как полноценное слово
✓ Экзамен s34: 16 563 отвала участвуют в условиях
11. Скорость: сегмент 6+ условий быстрее 5 с
✓ Экзамен s34 замеряет время ответа
12. Старое не сломалось
✓ Экзамены s33 14/14 зелёные после спринта
Один живой клиент попадал в указатель дважды
Мостик «сайт → номер клиента» строился в процессе раскладки, а не до неё.
✓ 9 случаев двойного счёта. Мостик собирается по всем источникам до раскладки.
Показатели считались за всё время, а не за период условия
✓ «Деньги плативших в августе» давали 2 715 555 ₽ вместо 2 259 820 ₽. Показатели берут период из условия. Закрыто экзаменом s34.
Совпадение значений было по части слова
✓ «Пакет Базовый» захватывал «Базовый 1000»: 26 265 клиентов вместо 14 129. Теперь совпадение точное, поиск по части — отдельной пометкой.
готовS10 · S35 — Страницы до регистрации и деньги с них10/10
Цель: Просьба Дениса: с каких страниц и цепочек страниц приходят регистрации и сколько они приносят денег.
Страницы до регистрации, доведённые до денег
✓ lib/regPages.ts + components/RegPagesBlock.tsx на вкладке «Регистранты». Экзамены tests/spec/s35-reg-pages.mjs — 9/9.
1. Разрез по страницам входа
✓ Экзамен s35: таблица по страницам
2. Разрез по цепочкам страниц
✓ Экзамен s35: одна, две, три+ страницы отдельно
3. Доведено до денег
✓ Экзамен s35: по строке видно клиентов и приходы
4. Только размеченные регистрации
✓ Экзамен s35 + подпись над таблицей
5. Период и разбивка по месяцам
✓ Экзамен s35: с 10.08, помесячно и итог
6. Вывод текстом с поправкой на размер выборки
✓ Интервал Вилсона: на малых числах вывод честный
7. Место — рядом с источниками регистрации
✓ Живой прод, вкладка «Регистранты»
9. Внутренние слои не показываем
✓ Склад исходников в интерфейс не выведен
8. Числа считает код: сумма по строкам = числу регистраций
✓ Экзамен s35 сверяет сумму регистраций по строкам таблицы с общим числом
готовS11 · S36 — Цепочки: пресет «К оплате»11/11
Цель: Обратный вопрос Дениса: не «сколько дошло по этой цепочке», а «какая цепочка принесла больше всего денег». Перебором в конструкторе он не решался.
Пресет «К оплате» в разделе «Цепочки»
✓ lib/chainsToPay.ts + components/ChainsToPayBlock.tsx. Экзамены tests/spec/s36-chains-to-pay.mjs — 8/8.
1. Кнопка-пресет «К оплате»
✓ Живой прод, вкладка «Цепочки»
2. Цепочки оплативших в выбранном месяце
✓ Экзамен s36: месяц и число оплативших
3. Сортировка: деньги, затем частота
✓ Экзамен s36 проверяет порядок строк
4. Клиенты, приходы, средний чек, доля
✓ Экзамен s36: все поля на месте
5. Переключатель месяца
✓ Экзамен s36: июль и август дают разные числа
6. «Открыть в конструкторе»
✓ Экзамен s36: шаги пригодны для конструктора
7. Конструктор не сломан
✓ Ручная сборка цепочек работает как раньше
9. Правила подсчёта — существующие
✓ Определение цепочки взято из конструктора
8. Числа считает код: деньги по цепочкам = приходам месяца
✓ Экзамен s36 сверяет сумму по цепочкам с разделом «Приходы»
Резать по первой оплате за всю историю было нельзя
Клиент, плативший весной и снова в августе, оставался «без событий до оплаты».
✓ Теряли 10 клиентов из 25. Режем по первой оплате ЭТОГО месяца.
В РАБОТЕS12 · S37 — Услуги, пакеты, тарифы и география12/14
Цель: Просьба Светланы: заложить знания про услуги, пакеты и тарифы, чтобы подбирать базу по портрету уже купивших. Плюс география шире поля «страна».
Чат понимает услуги, пакеты и тарифы
«Кластер» — не отдельная сущность, а линейка тарифа в поле «Услуга лота». Тариф устроен как «Уровень Линейка»: Платина/Золото/Серебро × Стандарт/Кластер/SEO-PRO/Бизнес/Всё включено/Вся Россия.
✓ Разрезы tariff, tariffLine, tariffLevel + словарь тарифов. Экзамены tests/spec/s37-tariffs.mjs — 10/10 на боевом.
1. «Сколько кластеров продали в августе» считает кластеры
✓ Экзамен s37 К1: кластеры отдельно от всех продаж
2. Разрезы по тарифу, линейке и уровню
✓ Экзамен s37 К2
3. Словарь тарифов разворачивается кодом
✓ Экзамен s37 К3: состав линейки модель не придумывает
4. Пакет портала и тариф не путаются
✓ Экзамен s37 К4: «Базовый 1000» и «кластер» дают разное
5. Сегменты по тарифу
✓ Экзамен s37 К5: тариф работает как условие сегмента
6. Портрет купивших линейку
✓ Экзамен s37 К6: рубрики, ЦУ, регионы, средний чек
7. Числа считает код
✓ Экзамен s37 К7: сумма по линейкам = приходам периода
8. Старое не сломалось
✓ На боевом s33 14/14, s34 17/17, s35 9/9, s36 8/8
Выгрузка в Excel из чата не работала
У обычного вопроса поле пула — строка «nk», а сегментный запрос заворачивался в объект с тем же именем. Код принимал строку за объект и получал 400.
✓ Жалоба Светланы закрыта. Экзамен tests/unit/export-query-kind.mjs — 5/5.
«Казахстан» искался только в поле «страна»
Поле «страна» в карточке почти не заполнено, поэтому «клиенты Казахстана» давали 2. Страна прячется ещё в регионах оплаты и в названии тарифа.
✓ Стало 9 клиентов с оплатами за январь-август против 2. Экзамен s37 К8.
Вопрос «за что заплатили» отвечал общей суммой
✓ Группировал по виду услуги, где 93% одно значение. Теперь по тарифу.
Определение «7 клиентов Казахстана» от Светланы
Ни одно определение не даёт 7: по слову с оплатами янв-авг — 9, только по полю «страна» — 2, по всей базе без оплат — 456, в потоке ПП и по другим пометкам — 6, 19 и 30. Подгонять число под ответ не стал.
⛔ Ждём от Светланы, каких именно клиентов она считает: поток НК или ПП, по стране в карточке или по региону оплаты, с какими услугами.
↑ Автоподбор похожих клиентов по портрету купивших
Вторая половина просьбы Светланы. Портрет купивших линейку уже считается (рубрики, ЦУ, регионы, средний чек), подбора похожих ещё нет.
В РАБОТЕS13 · S38 — Данные из CRM «Тюльпан» и Метрика клиентов2/4
Цель: Убрать ручную заливку xlsx: тянуть данные прямо из боевых баз. И закрыть провал по внешнему трафику клиентских сайтов.
Доступ к боевой CRM «Тюльпан» (поток НК)
Человек, который вёл туннели, уволился. Владелец прислал ключ напрямую.
✓ Ключ на cfru /root/.ssh/pulscen-crm.key (chmod 600), туннель на 6432 поднимается. PostgreSQL 17.9, база crm_pc, 207 таблиц: events 1 037 845, clients 583 707, payments 257 564. Только чтение, ничего не менялось. На 6432 стоит pgbouncer — он не принимает стартовый параметр options, поэтому режим чтения задаётся иначе.
Базы потока ПП (kirov:25501) закрыты фаерволом
Туннели рассчитаны на машину с внутренним адресом 10.0.0.139. С нашего сервера — таймаут. Письмо для технаря клиента подготовлено.
⛔ Нужен наш адрес в белом списке kirov:25501 на стороне Пульс Цен (по серверам — Быков Даниил). Без этого автосинк ПП невозможен.
Метрика клиентских сайтов: внешний трафик виден
Сетевой счётчик 200476 видит только витрины с портала, внешку (SEO, Директ напрямую на сайт клиента) — нет.
✓ Аккаунт common@support-sk.ru даёт 12 094 счётчика собственных сайтов клиентов. Проверено на www.tkstanki.ru (счётчик 41558234): за 30 дней 88 993 визита, из поиска 6 931 — внешний трафик виден. Решение: под каждого клиента цеплять его собственный счётчик. Механика подтверждена, в дашборд не вшита.
↑ Решить: тянуть всё из CRM или зеркалить текущие ручные выгрузки
В CRM миллион событий и 583 тысячи клиентов. Либо тянем всё и строим склад заново, либо повторяем автоматом ровно те выгрузки, что сейчас грузятся руками. Второе дешевле и не ломает сверки, первое даёт свежесть и новые разрезы.
В РАБОТЕS14 · Проверки по сроку4/8
Цель: Отложенные проверки «через неделю посмотреть, сработало ли». В detail — команда проверки, чтобы не исследовать заново.
Расход OpenRouter за первую неделю чата в пределах лимита
Лимит $20/мес. Проверка: ssh cfru "curl -s -x http://72.56.85.41:8888 https://openrouter.ai/api/v1/key -H \"Authorization: Bearer $OPENROUTER_API_KEY\"" — смотреть usage и limit. Ключ в /opt/pulse-analytics/.env. Если расход идёт быстрее лимита — включать кэш повторных вопросов.
✓ Ночная смена 01-02.10.2026. OpenRouter ключ Пульс Цен: usage 0,10 $ из лимита 20 $, остаток 20. Расход в пределах, кэш включать не нужно.
Открыли ли фаервол на kirov:25501 для потока ПП
Проверка: ssh cfru "timeout 10 bash -c '</dev/tcp/kirov.railsc.ru/25501' && echo open || echo closed". Открылось — поднимать туннель и сверять базы pulscen и pulscen_stat. Закрыто — напомнить Даниилу Быкову.
✓ Закрыто. 02.10 с cfru: timeout 10 bash -c '</dev/tcp/kirov.railsc.ru/25501' → Connection refused (closed). Фаервол не открыли, туннель поднимать и базы сверять нечего. Напомнить Даниилу Быкову — за владельцем.
⛔ Ночная смена 01-02.10.2026. kirov.railsc.ru:25501 — Connection refused, фаервол не открыт. Напомнить Даниилу Быкову.
Пользуются ли чатом с ИИ РОП и Светлана
Проверка: на cfru в базе /opt/pulse-analytics — число сессий и сообщений за неделю (таблицы ChatSession, ChatMessage). Пусто — значит разделом не пользуются, спрашивать почему, а не докручивать вслепую.
✓ Почти не пользуются. /opt/pulse-analytics/prisma/dev.db (ChatSession, ChatMessage) на 02.10: 6 сессий, 36 сообщений, из них 18 от пользователя. Всё в два дня: 21.09 (4 сессии, 14 сообщений: регистранты из Перми и Екатеринбурга, отвалы ЦУ СПБ) и 25.09 (2 сессии, 4 сообщения: база отвалов РТИ, регистранты ЦУ Сетевой отдел за август). С 25.09 по 02.10 ни одного сообщения. Кто писал, база не хранит (у сессии нет пользователя, mode=nk). Вывод: попробовали два дня и бросили; спрашивать РОП и Светлану почему, не докручивать вслепую.
Крон CRM: три ночи подряд без ошибок
⏱ 22.09 · просрочено 38 дн.
Тяга восстановлена 05.10 после простоя 27.09–05.10 (фаервол их сервера). Перезапуск проверки: три ночи подряд «готово» без «ОШИБКА». ssh cfru "tail -30 /opt/pulse-analytics/logs/crm-daily.log"
⛔ crm-daily.log (02.10): ночи 27.09, 28.09, 29.09, 30.09, 01.10 в 21:05 — «ОШИБКА: туннель к CRM не поднялся», ssh: connect to host pandora.railsc.ru port 21122: Connection refused. Последняя удачная ночь 26.09 («готово», bills 1191, actions 163). Три ночи подряд без ошибок проверить нельзя, пока нет туннеля. Встреча 02.10: Семён разбирается к понедельнику 05.10. После восстановления отсчитать три ночи заново и прогнать tests/spec/s39-crm-pull.mjs (К3 = 2 259 820).
CRM Тюльпан: поднялась ли ночная тяга (авария с 27.09)
⏱ 30.09 · просрочено 30 дн.
Тяга из CRM мертва с 27.09 — порт 21122 на pandora.railsc.ru отбивается со всех наших серверов. Пока порт не откроют, дашборд живёт на данных по 25-27.09. Проверка одной строкой: ssh cfru 'timeout 8 bash -c "echo > /dev/tcp/89.108.75.152/21122" && echo ОТКРЫТ || echo закрыт; tail -5 /opt/pulse-analytics/logs/crm-daily.log'. Открылся — дотянуть пропущенное окно: ssh cfru 'cd /opt/pulse-analytics && bash scripts/crm/daily.sh' (окна в скрипте с запасом, повтор безопасен). Закрыт — писать администратору Пульс Цен. Порядок диагностики: docs/CRM-MAP.md, раздел «Туннель не поднялся». С ПК владельца порты не проверять: Kaspersky подтверждает любое соединение.
S55: недельная пересборка связки с Метрикой отработала
Крон 20 22 * * 0 (01:20 МСК понедельника). Проверка: ssh cfru "tail -5 /opt/pulse-analytics/logs/metrika-weekly.log" — строка «связано сайтов …» и «готово» за 12.10/13.10; плюс grep terms /opt/pulse-analytics/logs/crm-daily.log | tail -3 — ночные сроки пакетов заливаются. Не сработало — запустить руками bash scripts/metrika/weekly.sh и смотреть ошибку.
✓ Зелёная (бриф 14.10). metrika-weekly.log: 2026-10-11 22:20:40 UTC «готово», связано сайтов 1509 (по домену 1417, по ид в адресе 92). Сроки пакетов из CRM заливаются каждую ночь: 11, 12 и 13.10 по 20 086–20 121 строк, залито = выгружено.
VK Реклама ПЦ: жив ли токен от поддержки через сутки
⏱ 24.10 · просрочено 6 дн.
23.10 поддержка VK выдала готовый access_token на кабинет 20363762 (eLama, ПЦ club46008352 + канал MAX владельца). Ключей client_id/secret нет, обновить сами не можем; обычный токен VK живёт сутки.
Проверка: ssh aitodo "/root/.secrets/vk-pc.sh GET v2/user.json" — ждём id 20363762.
Если 401/invalid_token: писать на ads_api@vk.team, просить токен с refresh_token или бессрочный. Карта: VK-MACHINE.md §0.12.
↑ S63: снимок октября регистрантов снялся 1–3 ноября
⏱ 04.11 · через 5 дн.
Проверить, что ночная тяга 1–3.11 сняла октябрь целиком и с 4.11 его не трогает. Команда: ssh cfru "grep registrants /opt/pulse-analytics/logs/crm-daily.log | tail -8" — должны быть строки «registrants 2026-10-01..2026-10-31» за 1–3 ноября, 4.11 окно с 2026-11-01. Затем сводник: curl -s -u $AUTH http://127.0.0.1:3061/api/regi/summary | jq ".months[-2]" и сверить октябрь с «Сводником по Модерации» аналитика, когда она его заполнит (Принята+для ведения в допуске 1,5%).
готовS15 · S39 — Данные тянем из CRM, а не грузим руками9/12
Цель: Наказ владельца: выгрузить всю информацию за 2026 (события, оплаты, звонки, регистрации, взятие в работу, действия менеджеров), а по ПП — обновить всё с 2023 года. ПП тоже лежит в Тюльпане, не на kirov.
Разбор схемы боевой CRM и карта механики
207 таблиц, миллион событий, 9 млн действий менеджеров. Раньше механику разбирали с нуля каждый раз.
✓ Карта в docs/CRM-MAP.md: связки таблиц, объёмы по годам, дерево регионов, периметр ручных выгрузок, правило «Порядка оплаты» и все пойманные грабли. Все запросы только на чтение (begin read only).
Приходы: тяга из CRM с 2023 года
✓ Залито 44 месяца подряд: 2023-01 — 2026-08, 64 455 строк против 927 было. Сверка на августе: ключи «счёт + дата» совпали ровно (625 и 625), деньги сошлись в 617 из 625, остальные 8 — правки, внесённые в CRM после выгрузки. Экзамены tests/spec/s39-crm-pull.mjs 5/5.
1. Приходы есть в каждом месяце с 2023 по август 2026
✓ Экзамен К2: 44 месяца с деньгами, пустых нет
2. Деньги НК за август не изменились
✓ Экзамен К3: 2 259 820 ₽, как и было принято
3. Повторная тяга не плодит дублей
✓ Экзамен К10: загрузчик отказывает с кодом 2
4. Чат и раздел «Приходы» дают одну сумму
✓ Экзамен К12 на марте 2026
События за 2026: тяга из CRM
В ручной выгрузке был только пул НК, поэтому четырёх типов событий не было вовсе.
✓ Событий за 2026 стало 53 368 против 31 008. Добавились «Входящий звонок», «Хочу заказы», «Просмотрел прайс лист баннеров», «Холодный лид» и события платящих клиентов. Заливка аддитивная с дедупом: на августе 4 356 строк узнаны как уже залитые, добавлено 2 443. Пул НК не поехал, экзамены S33-S37 зелёные.
Взятие в работу по каждому событию
В CRM у события есть отметка обработки, время взятия и признак превышения норматива (events.processed, processed_at, exceeds_standard против event_types.processing_standard).
✓ Поля заведены в модель события и в разбор, данные тянутся и сохраняются. Осталось показать их в интерфейсе и научить чат вопросу «сколько событий не взято в работу».
↑ Звонки и действия менеджеров за 2026
Разобрано: звонки — asterisk.cdr (calldate, duration, billsec, disposition, запись), действия — operations (менеджер, цель, результат, ВОЗРАЖЕНИЕ из справочника rejects, статус, ЦУ). Перед заливкой обязательно сверить длительность звонка с ручной выгрузкой: ключ дедупа включает длительность, и расхождение задвоит звонки.
География по справочнику регионов CRM
Страна = корень дерева регионов. Казахстан — 12 городов, Беларусь — 13, Украина — 23. Раньше искали по слову и теряли Алматы, Караганду, Астану.
✓ Списки городов взяты из CRM, сравнение городов точное. Поймана своя же ловушка: «Уральск» входит в «Уральский федеральный округ», поиск вхождением записывал пол-России в Казахстан. Экзамен s37 К8.2.
Ответ по клиентам Казахстана для Светланы
Вопрос был «сколько клиентов Казахстана купили размещение январь-август», ответ дашборда был 2, у Светланы 7.
✓ Причина найдена: оплат за январь-апрель в дашборде не было вовсе, плюс география искалась по слову. Теперь по данным: в потоке НК 12 клиентов с оплатами за период. По всей CRM: компания из Казахстана — 116, регион лота казахстанский — 126, НОВЫХ (первая оплата в периоде) — 8, с именами и датами в docs/CRM-MAP.md. Число не подгонял: отдаём список, Светлана says кого из восьми не считает.
Единый периметр: перезалить май-сентябрь 2026 из CRM
Месяцы с мая по сентябрь пришли из ручных выгрузок, где только 11 ЦУ. Месяцы из CRM — по всем ЦУ. Из-за этого помесячная картина «все потоки» имеет ступеньку с мая. На цифры потока НК это не влияет.
⛔ Нужно решение владельца: перезаливка заменит уже принятые строки мая-сентября. Деньги НК за август могут измениться на величину правок, внесённых в CRM после ручной выгрузки (8 строк из 625).
готовS16 · S40 — Регистранты: только прошедшие модерацию8/10
Цель: Решение владельца: чистить отклонённые и удалённые, показывать сумму «Принята» + «Одобрена». Родилось из сверки аналитика с выгрузкой Лены: 742 против 620.
Чистка отклонённых и удалённых в регистрантах
Разбор расхождения 742 против 620: данные совпадают, разное правило подсчёта. У аналитика в своде только «Принята» + «Одобрена».
✓ Правило в одной функции getRegiRecords() — через неё идут раздел, сравнение месяцев, выгрузка Excel и чат. Август стал 564 вместо 742. Экзамены tests/spec/s40-regi-moderation.mjs — 5/5, S33-S37 и S39 зелёные, типы чистые.
1. В регистрантах нет отклонённых и удалённых
✓ Экзамен К1: 5 311 строк, посторонних статусов 0
2. Август стал 564 вместо 742
✓ Экзамен К2
3. Первая половина года не поехала
✓ Экзамен К3: январь-июнь без изменений
4. Правило одно на весь дашборд
✓ Экзамен К4: чат и раздел дают 564
5. Справочник «клиент → ЦУ» чистку не проходит
✓ Экзамен К5: иначе события уедут в «не определён»
6. Правило подсчёта видно в интерфейсе
✓ Строка под показателями, проверено на живой странице
Месяцы были несравнимы между собой
В выгрузках до июля статус приходил уже очищенным (все «Принята»), а с июля — сырым.
✓ Июль-сентябрь были завышены относительно первой половины года: за август 742 против 564 реальных. После чистки ряд по месяцам сравним.
↑ Статус модерации уезжает со временем
Проверено по CRM: из 55 сайтов августа со статусом «Одобрена» в выгрузке от 03.09 к 18.09 53 отклонены и 2 удалены, плюс 5 «Принята» стали отклонёнными. Число принятых за август упало с 620 до 561 и продолжит падать.
↑ Источники регистрации не проходят чистку
Блок на той же странице считает по СОБЫТИЯМ регистрации, а не по файлу РЕГИ. За сентябрь видно 186 регов и 475 размеченных регистраций: мастер-файл РЕГИ отстаёт от событий. Лечится тягой регистрантов напрямую из CRM.
готовS17 · S41 — Сверка с отчётом аналитика за август8/10
Цель: Владелец прислал рабочий файл аналитика (исходники, свод и инструкция формирования отчёта) и попросил найти, где расходимся и почему.
КЦ активности: считаем как в своде аналитика
У аналитика за август 233, у нас было 267. В «КЦ активности» попадали сервисные касания: смена адреса, рассылки, диалоги в мессенджерах.
✓ 34 клиента жили ТОЛЬКО в сервисных целях — отсюда весь разрыв. Правило вынесено константой KC_ACTIVITY_EXCLUDED_GOALS в lib/planCalc.ts. Стало 233 — ровно её цифра, проверено на живой странице Плана месяца. Экзамены tests/spec/s41-plan-kc.mjs 4/4.
1. Сервисные цели перечислены в коде
✓ Экзамен К1: список берётся из самого lib/planCalc.ts
2. КЦ активности за август = 233
✓ Экзамен К2
3. Разрыв объясняется по данным
✓ Экзамен К3: 267 со всеми целями, 233 без сервисных, ровно 34 разницы
4. КЦ потенциальный не задет
✓ Экзамен К4: 36 клиентов, как и было
Разбор инструкции формирования отчёта аналитика
В файле нашлась инструкция: какие события идут в отчёт, какие ЦУ считаются НК, что чистится руками.
✓ Записано в docs/ACCEPTANCE-S41.md. Проверено по шагам: наш пул НК 741 -> только её 8 ЦУ НК 632 -> плюс чистка рассылки 621. Это РОВНО её ИТОГО за август. Значит данные у нас и у неё одни и те же, расходились правила.
Регистранты августа приведены к её файлу (620)
Наказ владельца: сделать 620 по ид сайта, как в файле Лены.
✓ Загрузил её файл, август стал 620 (565 принята + 55 одобрена). Экзамены S40 5/5, чат и раздел дают одно число.
Даты регистраций съезжали на сутки назад
1 августа 00:00 из xlsx превращалось в 31 июля 23:59:27 — артефакт перевода дат Excel в местное время.
✓ 10 августовских регистраций уезжали в июль. Дата читается серийным числом и хранится полночью по UTC, как события и приходы. Разово нормализовал 742 строки в базе. Экзамен S40 К4: раздел и чат дают одно число.
Расхождение по прайс-листу: 362 против 304
Разобрано до клиента: из 529 наших клиентов августа 309 попадают в её периметр ЦУ (у неё 304), а 220 — вне: без ЦУ менеджера 48, Челябинск 31, Дирекция 26, Беларусь 23, Пермь 18, Москва 18, Екатеринбург 18, Новосибирск 17, СПб 13, Ростов 7, Франшиза 1.
⛔ Нужно решение владельца: сужать ли периметр дашборда до её 8 ЦУ НК (сделать переключателем) или оставить шире и объяснять разницу.
↑ 48 событий августа без ЦУ менеджера
Сейчас они в пуле, у аналитика их нет. Скорее всего раскладываются по региону, как мы уже делаем с остальными событиями.
готовS18 · S42 — История НК из CRM и ежедневная тяга6/7
Цель: Наказ владельца 19.09: догрузить НК за 2024-2025 из Тюльпана, ответить по ПП, сделать крон, который каждую ночь тянет данные за прошлый день.
События НК за 2024-2025 из CRM
✓ Залито локально: 2024 — 90 862, 2025 — 85 827 (плюс 2026 — 53 372). Тяга по месяцам, дедуп по ключу события. Экзамены S33-S41 зелёные, 73 проверки.
Ежедневная тяга из CRM (крон)
scripts/crm/daily.sh: события за 2 дня, приходы за 45 дней, дедуп по «счёт + дата». Секреты из .env приложения. Ключ --dry для проверки без записи.
✓ Крон включён на cfru 19.09.2026: 5 21 * * * (00:05 МСК). Сухой прогон на проде прошёл. В конце прогревает кэш событий. Первый боевой прогон — ночь на 20.09.
Приходы: дедуп вместо жёсткого запрета на период
Раньше загрузчик отказывал, если за период уже что-то есть. Для ежедневной тяги это не годится: нужно доливать новое, не трогая старое.
✓ Дедуп по паре «счёт + дата» + запасной ключ для строк без счёта. Плюс выяснилось, что дашборд и сам дедуплицирует приходы по ключу платежа — двойной счёт невозможен. Пустые загрузки убираются из склада автоматически. Экзамен S39 К10 зелёный.
Портфель ПП из CRM
Приходы ПП с 2023 подтянуты (все ЦУ). Но раздел ПП строится на выгрузке «Аналитика для продаж»: товарная масса, метки проработки, фасеты, трафик Яндекс/Google/портал, группы. Это данные ПОРТАЛА, они на kirov, в Тюльпане их нет. Из CRM можно собрать только «что у кого куплено»: тариф, пакет, услуга лота, даты, ЦУ, менеджер, число товаров.
⛔ Нужно решение: собирать из CRM урезанный портфель (без качества товаров и трафика) или добиваться доступа к kirov (наш адрес в белый список).
🔴 Выкат S39-S42 на прод + включение крона
Порядок: 1) код на cfru, сборка, перезапуск; 2) в .env добавить CRM_DB_PASSWORD; 3) прогнать тягу на проде: приходы 2023-01..2026-04, события 2024-01..2026-09 (около часа, дедуп делает повтор безопасным); 4) загрузить файл Лены для 620; 5) включить крон; 6) прогнать экзамены на проде. Схема базы не менялась, миграций нет.
✓ Выкачено 19.09.2026 по ДА владельца. Бэкап базы и склада в /tmp на cfru. Засыпка истории на проде: приходы 2023-01..2026-04, события 2024-01..2026-09, регистранты сентябрь, файл Лены для 620. Экзамены на проде: 73/73. Крон включён: 5 21 * * *. После засыпки полный пул событий весил 140 МБ — /api/events отдаёт окно 13 месяцев, чат видит всю глубину.
Выгрузка событий не отдавала Критерий, Сайт, Менеджера и ЦУ менеджера
Вопрос владельца «данные из CRM проходят все правила?» вскрыл дыру: без этих колонок чистка по критерию и тестовым сайтам не срабатывала, а сегмент НК/ПП падал на запасное правило по пакету. За август так прошло 842 строки со служебным критерием и 47 тестовых сайтов.
✓ Колонки добавлены (критерии из company_criteria, менеджер и его подразделение из закреплений). 199 053 строки из CRM стёрты и залиты заново с чисткой: 2024 — 78 665, 2025 — 75 588, 2026 — 48 726. Сверка с аналитиком по её правилам: 622 против 621. Экзамены 73 зелёных.
Регистранты из CRM в ежедневной тяге
Формат портального отчёта по компаниям, тот же, что у файла аналитика. Окно 10 дней: статус модерации обновляется 10 дней после регистрации, потом замораживается — закрытый месяц не переписывается.
✓ Проверка на августе: 808 строк, ровно как у аналитика. Локально: сентябрь вырос с 264 до 495, август остался 620. Сухой прогон на проде: 315 строк за 10 дней.
готовS19 · S43 — Чат: разбор живых вопросов с прода5/6
Цель: Владелец: «ИИ сильно тупит и делает не то». Сняты все 14 вопросов за 21.09, каждая ошибка разобрана до причины в коде.
Отвалы искались по городу, которого у них нет
У отвалов в указателе есть регион, но нет города. Фильтр по городу резал 16 563 отвала до 1. Три вопроса из 14 умерли на этом.
✓ Город и регион смотрятся вместе, сокращения понимаются (СПб, Питер, Екб, Мск, Нск, НН). «Отвалы Екатеринбурга» дают 2 119 клиентов.
Продолжение «сколько из них оплатили» теряло население
После «регистранты 2026 из Перми» считались все клиенты Перми за всю историю.
✓ Добавлено условие «зарегистрирован в периоде». Разборщику дан пример переноса населения.
Не было разрезов по времени ни у одной базы
«Динамика регистрантов по месяцам» отвечала «нет такого признака: month».
✓ У всех баз появились месяц, неделя, день; порядок календарный, а не по величине. Плюс разрезы regMonth и payMonth у сегментов.
«ЦУ СПБ» — город, а не центр учёта
✓ ЦУ у нас ровно три. Город в поле ЦУ теперь ищется по региону с пометкой в воронке, а не отвечает «такого значения нет».
Новые условия и разрезы по живым вопросам
✓ «Последняя оплата в периоде» (закончили размещение в 2023), разрез по продавцу, ид сайтов в списках. Экзамены tests/spec/s43-chat-real-questions.mjs 9/9 (сначала упали).
↑ Прогон живых вопросов через саму модель
tests/spec/s43-llm-replay.mjs — 5 диалогов, ~1 ₽ через OpenRouter. Проверяет структуру собранного запроса, а не текст ответа.
готовS20 · S44 — Скорость дашборда9/9
Цель: Владелец 23.09: «дашборд стал сильно тормозить и долго грузится».
Приходы читались целиком и без кэша на каждый запрос
После засыпки истории строк стало 65 948 вместо 927. /api/pay-map и /api/payments — по 5 секунд КАЖДЫЙ раз, и так на каждой странице.
✓ Кэш по версии данных (строки + последняя заливка), сбрасывается сам при загрузке файла. Стало 12-15 мс.
Поиск пар возврата был перебором в переборе
✓ Заменён указателем «клиент + дата + сумма». Числа не изменились: экзамены S33-S43 зелёные.
Пул событий раздут пустыми полями и текстами действий
✓ 45,1 → 32,3 МБ: пустые поля не отправляются, текст действия режется до 300 знаков (целиком живёт в карточке клиента).
1. Карта приходов быстрее 1 с
✓ Экзамен К1: 12 мс, было 5,2 с
2. Раздел «Приходы» быстрее 1,5 с
✓ Экзамен К2: 13 мс, было 5,0 с
3. События быстрее 2 с, пул не тяжелее 35 МБ
✓ Экзамены К3 и К3.2: 32,3 МБ
4. Все данные страницы быстрее 3 с
✓ Экзамен К4: 280 мс на 6 запросов
5. Сегмент в чате быстрее 5 с
✓ Экзамен К5
↑ Сводки считать на сервере вместо отдачи всего пула
Браузеру уходит 32 МБ за 13 месяцев, и каждая страница считает сводку по 42 тысячам событий у себя. Скачать и разобрать — 0,4 с, пересчёт в интерфейсе — основная часть первого открытия. Настоящее лечение — спринт S32 «Ядро данных». Промежуточно: окно 7 месяцев или догрузка истории фоном.
✓ Сделано в S45 (этап 1): Обзор считает сервер, POST /api/dash-view. Данных на заход 20,9 МБ -> 497 КБ, последний ответ 6,2 с -> 0,24 с, переключение ЦУ 2-3 с -> 0,06-0,39 с. Экзамены 13/13
готовS21 · S45 — Сводки считает сервер (этап 1: Обзор)17/21
Цель: Браузер получает готовые числа, а не пул событий: Обзор на POST /api/dash-view
↑ Готовая сводка Обзора с сервера (POST /api/dash-view)
lib/core/dashView.ts считает теми же функциями lib/aggregate, тем же правилом ЦУ и тем же правилом денег (приходы за период), что считал браузер
✓ Экзамены 13/13 (tests/spec/s45-server-view.mjs). Ответ 137 КБ за 30-160 мс. Обзор переведён: данных на заход 20,9 МБ -> 497 КБ, последний ответ 6,2 с -> 0,24 с, переключение ЦУ 2-3 с -> 0,06-0,39 с
К1 сводка приходит готовой: показатели, воронка, регионы, менеджеры, деньги, корзины
✓ СДАН: показателей 12, регионов 151
К2 цифры совпадают с подсчётом по сырому пулу
✓ СДАН: лидов 1355=1355, событий 3295=3295, корзины 741/312/140/162, типов 18
К3 суммы сходятся (корзины, регионы, деньги)
✓ СДАН: корзины=лидам; события по регионам 3295=3295; деньги 1 505 345 = приходам периода по этим клиентам
К4 фильтры на сервере, разбивка по ЦУ не теряет лидов
✓ СДАН: МСК 330 + СО(ЕК+ПМ) 324 + СО РОССИЯ 705, объединение 1355 из 1355, потерь нет
К5 ответ меньше 200 КБ и быстрее 1 с
✓ СДАН: 140 КБ за 28-350 мс
К6 КЦ активность = отчёту по действиям
✓ СДАН: 666 действий / 267 клиентов в сводке и в отчёте
К7 состав корзины считает сервер по клику
✓ СДАН: в корзинах 1355 = лидам, строк не больше 100, в браузере 0,39 с
К8 экзамены S33-S44 зелёные
✓ СДАН: 14/14, 17/17, 9/9, 8/8, 11/11, 5/5, 4/4, 9/9, 6/6 (S39 4/5 — К10 без CRM_SAMPLE_CSV, как и раньше)
Карточка клиента открывалась 7,3 секунды
/api/client собирал карточки ВСЕХ клиентов пула (126 тыс. событий), чтобы найти одного
✓ Сперва отбор строк клиента, потом сборка. 7,3 с -> 0,08 с в браузере (тёплый сервер), 44 мс на API
Сравнение периодов грузит пул только когда блок раскрыли
✓ LazyPeriodCompare: 856 мс на раскрытие, августовские 1 452 лида сходятся со сводкой
Список Критерии: 10 530 значений свободного текста из CRM
1 МБ в ответе и нерабочий выпадающий список
✓ Отдаём 200 самых частых, фильтр по любому значению работает (считает сервер). Правильное решение — разделить справочник и комментарий менеджера на тяге
↑ Этап 2: серверные сводки для остальных разделов
Регистранты, приходы, звонки, цепочки, каналы, баннеры, входящие, рассылки + эндпоинт метрик для сравнения периодов
Этап 3: убрать пул событий из браузера совсем
Останется раздел События со своими разрезами — ему нужен отдельный серверный разрез
↑ Выкат S43-S45 на прод
Ждёт явного да от владельца
✓ Выкачено 23.09.2026 на cfru. Экзамены S33-S45 зелёные прогоном с самого сервера, все страницы 200. Данных на заход в Обзор 90 КБ, переключение ЦУ 0,2-1,0 с
🔴 Прод и браузер считали разный август (часовые пояса)
Прод в UTC, машина разработчика в МСК: одна и та же выборка давала 1362 против 1355 лидов. Границы периода строились по местной полуночи, а в базе лежит екатеринбургское время, записанное как UTC
✓ Правило времени вынесено в lib/time.ts и применено везде (события, КЦ, звонки, ПП, рассылки, сравнение периодов). Прод-числа не изменились, изменились браузерные — они и были сдвинуты. Записано в docs/CRM-MAP.md
🔴 Строка ИИ на проде отвечала 500: таблицы DashboardBlock не было
Таблицу создали в разработке через prisma db push, миграцию не завели, на прод она не уехала
✓ Миграция 20260923100000_dashboard_block заведена и применена (с остановкой приложения — SQLite иначе locked). В DEPLOY.md добавлен шаг сверки схемы с продом ДО выката
Ответы API не сжимались
Next этот JSON сам не жмёт: в ответах нет Content-Encoding
✓ lib/http.ts + сводка, карта приходов, справочник ЦУ: данные Обзора 501 КБ -> 90 КБ
Примесь КЦ пересобиралась на каждый запрос
126 тыс. событий перемешивались заново, первое переключение ЦУ на проде занимало 4 с
✓ Мешаем один раз на пул и запоминаем, фильтр ЦУ применяется после примеси. Холодный ЦУ 0,15-0,5 с
↑ Экзамен на расхождение схемы БД и боевой базы
Сейчас сверка руками командой из DEPLOY.md. Нужен экзамен, который валится, если в schema.prisma есть модель, которой нет в боевой базе
Прогрев после перезапуска вынести в скрипт
Первый запрос после pm2 restart собирает пул 12 с на сегмент. Сейчас прогрев руками по инструкции
готовS22 · S46 — Счета из CRM: долги и открытые счета в ПП7/8
Цель: Счета приезжают ночью вместе с приходами; у продавца видно долг, открытые счета и «оплаты не будет»
↑ Тяга счетов из CRM + показ долга в ПП
scripts/crm/bills.sql + вид отчёта bills + ночной крон окном 45 дней + долг и открытые счета у продавца
✓ Готово локально, экзамены 11/11 + регрессия S33-S45. ВЫКАТ ОТЛОЖЕН по просьбе владельца 24.09 (встреча по дашборду). Добавлена защита: отменённые в CRM счета удаляются при следующей тяге (проверено — убрали 10 из выгрузки, все 10 ушли). На клиента в блоке продавца всегда одна строка: последний счёт + суммарный долг
К1 счета тянутся из CRM в том же виде, что ручная выгрузка
✓ scripts/crm/bills.sql: один счёт = строка, суммы и услуги свёрнуты по лотам. Выгружено 1500 счетов за 25.07-24.09
К2 сверка с файлом владельца: 737 счетов, 81 809 123 суммы, 43 240 519 долга за 03.08-24.09
✓ Все 737 счетов файла найдены, сумма 81 809 123 и долг 43 240 519 сошлись до рубля. Эталон заморожен в tests/fixtures/s46-bills-reference.json
К3 повторная тяга не задваивает (ключ — номер счёта), суммы и оплаты обновляются
✓ Ключ — номер счёта (уникальный индекс), повторная загрузка того же файла: строк осталось 1500, суммы обновляются
К4 у продавца видно долг, открытые счета и «оплаты не будет»
✓ В блоке «Пакет заканчивается» появились счёт, долг и «оплаты не будет»: из 4857 строк долг виден у 547. Проверено глазами на /pp
К5 счета в ночном кроне окном 45 дней
✓ scripts/crm/daily.sh: pull bills окном 45 дней, рядом с приходами
К6 чистка по общему правилу ЦУ, без отдельного периметра счетов
✓ Тянем все ЦУ, на экранах режем общим правилом lib/cu.ts. Периметр ручной выгрузки оставлен только для сверки экзаменом (perimeter=file)
К7 экзамены S33-S45 зелёные
✓ Локально зелёные: s46 10/10, s45 13/13, s44 6/6, s43 9/9, s41 4/4, s40 5/5, s37 11/11, s36 8/8, s35 9/9, s34 17/17, s33 14/14
готовS23 · S47 — План месяца: честный прогноз при разной свежести данных9/10
Цель: Прогноз считается по дням того источника, откуда категория берёт факт; видно, где данные кончились
🔴 План месяца показывал красное там, где его нет
Владелец: две недели было 95-100%, стало почти всё красное, особенно КЦ активности
✓ Две причины. (1) Отчёт по действиям КЦ на проде залит по 18.09, события идут ночью по 25.09 — факт КЦ за 18 дней делился на 26 прошедших. (2) Моя регрессия от 23.09: после перехода на UTC отсечка считалась по UTC, а номер дня по местному времени — «прошло 26 из 30» вместо 25. Починено: расчёт на сервере, темп по дням своего источника, плашка о свежести
К1 август не меняется: КЦ активности 233, потенциальный 36, анкета 261, МОРС 62, товары 41
✓ СДАН. Прайс 332→334 и СК 108→107 — не смена правил, а граница суток: месяц теперь по календарю ЕКБ (lib/time), браузер москвича резал на 3 часа раньше
К2 дни считаются верно: на 25.09 прошло 25 из 30
✓ СДАН. Было 26 из 30
К3 прогноз по дням своего источника
✓ СДАН. КЦ активности считаются по дням с действиями, события — по своим; прогноз КЦ 83% вместо 30%
К4 видно, по какое число загружены действия КЦ
✓ СДАН. Плашка на экране плана
К5 источники не перепутаны: КЦ из действий, остальное из событий
✓ СДАН. Проверено экзаменом по полю source
К6 числа считает сервер (POST /api/plan-view)
✓ СДАН. Иначе расчёт нельзя проверить экзаменом
К7 экзамены S33-S46 зелёные
✓ СДАН. s46 11/11, s45 13/13, s44 6/6, s43 9/9, s41 4/4, s40 5/5, s37 11/11, s36 8/8, s35 9/9, s34 17/17, s33 14/14
Разрез «По ЦУ» считал КЦ активности по своему правилу
В главной таблице сервисные цели (смена адреса, рассылки, диалоги в мессенджерах) исключались, в разрезе — нет
✓ Одно правило isKcActivityGoal в обоих местах. Плюс даты разреза переведены на общее правило времени — вкладки сошлись строка в строку
↑ Загрузить свежий отчёт по действиям КЦ
На проде действия по 18.09, звонки по 18.09. Пока файла нет, строки КЦ в сентябре неполные — прогноз честный, но факт занижен
готовS24 · S48 — Действия КЦ из CRM вместо ручного файла8/9
Цель: КЦ приезжает ночью из Тюльпана; правила счёта и августовский эталон не меняются
↑ Тяга действий КЦ из Тюльпана
✓ scripts/crm/actions.sql + вид отчёта crmactions + ночная тяга окном 14 дней. Сентябрь перестал обрываться: план 100% против прежних 63%, КЦ активности прогноз 105% вместо 59%
К1 август не меняется: КЦ активности 233, потенциальный 36
✓ СДАН, экзамен s47/s41
К2 действия приезжают из CRM (вид crmactions)
✓ СДАН, 322 действия за 1-25.09
К3 одно действие — одна строка (ключ — номер действия)
✓ СДАН. Номер в файле формулой-гиперссылкой, в тяге числом — сравниваем только номер
К4 ручные данные не затираются
✓ СДАН. Тяга удаляет свои строки и точные совпадения по номеру; поймано на том, что снесло ручные за 1-13.09
К5 окно тяги 14 дней, закрытые месяцы не переписываем
✓ СДАН
К6 экзамены S33-S47 зелёные
✓ СДАН
↑ Решить, кого считать колл-центром
В коде четыре имени операторов. В сентябрьском файле авторы шире: Шнейдер, Кучеренко, Екенина, Лукманова, Шейко из подразделения «Контакт-центр» — их действия отбрасываются. Если считать, сентябрьские КЦ активности вырастут примерно на 27 клиентов
Даты действий из ручного файла были в местном времени
Одно действие из файла и из тяги получало даты со сдвигом и попадало в базу дважды (58 строк сентября)
✓ Обе стороны переведены на общее правило lib/time; ключ действия нормализован по номеру
готовS25 · S49 — План на следующие три месяца7/7
Цель: План на окт-дек 2026 по очищенному факту тех же месяцев 2025 года
↑ Поставить план на октябрь, ноябрь и декабрь
✓ Выкачено 25.09.2026. Октябрь 1106, ноябрь 1082, декабрь 951 — по очищенному факту тех же месяцев 2025. Скрипт scripts/plan-from-year-ago.mjs, повтор безопасен
К1 план стоит на три месяца по семи категориям
✓ СДАН
К2 план равен очищенному факту год назад
✓ СДАН, категория в категорию
К3 прежние месяцы плана не изменились (август 1095, сентябрь 1133)
✓ СДАН
К4 месяц-источник закрыт данными
✓ СДАН, скрипт отказывается ставить план по оборванному месяцу
Действия КЦ за окт-дек 2025 дотянуты из CRM
✓ 461 + 398 + 337 действий. Проверено: в конце 2025 работали те же четыре оператора, данные сопоставимы
Будущие месяцы не показывались в выборе месяца
Список строился только по месяцам с событиями — поставленный вперёд план человек бы не увидел
✓ В список добавлены месяцы, на которые есть план
ревьюS26 · S50 — Доработки дашборда продавца3/4
Цель: Тариф и пакет в «Не проработано», полные поля карточки в Excel, связка счётчика Метрики с ид сайта
В «Не проработано товаров» под клиентом — тариф и пакет
Было название сайта, а оно почти всегда повторяет имя клиента — строка выглядела дублем
✓ Готово локально: «ВсеИнструменты.ру — Старт · Платина», как в «Пакет заканчивается». Проверено на экране
В Excel не попадали данные карточки клиента
Владелец: нет рубрик без приоритетных товаров и прочего с карточки
✓ Проверено живьём 29.09: кнопки нажаты в браузере, файлы скачаны и прочитаны. «Не проработано товаров» — 33 колонки, «Пакет заканчивается» — 46. Отдельно нашлась главная причина жалобы: кнопка Excel на самом «Моём дашборде» давала урезанные листы (5 и 17 колонок) — туда карточные колонки не подставлялись вовсе; теперь 32 и 42. Карточные колонки собраны в одном месте (cardColumns) и используются всеми выгрузками продавца. Добавлены три показателя из блока карточки «Трафик и переходы», которых не было нигде: просмотры, посетители и переходы на интернет-магазин за 12 месяцев — считаются по хвосту ряда самого сайта, чтобы Excel не расходился с экраном. Сверка на Галеон-СК: 972 / 142 / 991, охвачено рубрик 52, рубрик без приоритетных 52, товаров без фото 3, групп 106 — совпало с карточкой до единицы. Критерии записаны в docs/ACCEPTANCE-S50.md. Не выкачено: ждёт «да» владельца.
↑ Связка «счётчик Метрики ↔ ид сайта» в Тюльпане
05.10, проверено до конца. Домены в CRM есть (company_sites: ид сайта → свой сайт клиента). Аккаунтов Метрики 17, все живые, 19 892 счётчика, токены в secrets/metrika-accounts.json (600). Покрытие платящих 491 из 4 885 (10%) при любой логике сопоставления — потолок доступа: у ~2 200 платящих со своим сайтом счётчики в их собственных аккаунтах. Регистрантов НК со связкой 2 из 6 333. Дальше: гостевой доступ клиентов к нашему аккаунту или база портала (вопрос Казакову). Ждёт решения: строить блок на 491 сайте.
🔴 🔴 ИНЦИДЕНТ: ночная тяга из CRM не работает с 27.09
Проверено 29.09.2026 тремя независимыми точками — cfru (РФ), aitodo (РФ), amnezia (Амстердам). Порты 21122, 22 и 443 на 89.108.75.152 отбиваются со всех трёх (Connection refused) при живом контроле (/dev/tcp/ya.ru/443 открыт с каждой). DNS одинаковый у 8.8.8.8, 1.1.1.1 и 77.88.8.8 — 89.108.75.152, адрес не менялся. Ключ хоста [pandora.railsc.ru]:21122 есть в known_hosts на cfru — команда и порт правильные, соединение раньше было. Журнал logs/crm-daily.log: одна и та же строка скрипта работала каждую ночь до 26.09 21:05 и с 27.09 даёт refused; скрипт руками не трогали, запускает крон. Пинг проходит, но обратная зона — agava.net, у Агавы на ICMP отвечает сеть, так что это не признак живой машины. Вывод: сторона CRM. Нужен их администратор. Порядок проверки записан в docs/CRM-MAP.md, раздел «Туннель не поднялся». Данные встали: события по 27.09, счета, оплаты и действия КЦ по 25.09.
✓ 05.10 ответ их ИТ: 27.09 на pandora.railsc.ru обновляли сервер, потерялось правило фаервола под 80.90.184.203. Правило вернули, туннель поднялся с первой попытки. Пропуск 27.09–05.10 дотянут: события окном простоя (1 278 строк, 737 новых, 541 совпали с ручными файлами владельца и отсеялись на входе), затем daily.sh целиком без ошибок — регистранты 204, приходы 522, счета 1 095, действия 176. Задвоения нет: 345 новых CRM-событий за 27–30.09 — типы, которых не было в ручной выгрузке (пропущенные и входящие звонки, «Интерес к закупкам»). Контакт на повтор: их системный администратор Кирилл Мамедалиев. Записано в docs/CRM-MAP.md.
ревьюS27 · S51 — План по лидам на 20271/5
Файл плана 2027 в разметке владельца
✓ Сделан scripts/plan-2027/«Пульс цен — план по лидам 2027.xlsx». Разметка повторяет файл 2026: месяцы по колонкам, у каждой категории пять строк (план, факт, % вып, Прогноз, Прогноз в %), сверху итоги по уровням, порядок категорий как в PLAN_CATEGORIES. План проставлен, факт пустой; три производные строки — формулы. Прогноз = факт / прошедшие дни месяца × дни месяца, прошедшие дни считает служебная строка от TODAY(); для будущих месяцев пусто, а не #ДЕЛ/0!. Итог плана 13 671 против 13 750 на 2026. Файл обновлён и на внутренней странице /lab/pulscen-plan-lidov-2027 (200).
Экзамены на файл плана: формулы и разборщик
✓ check_formulas.py считает формулы заново на своей модели листа (дата замера 12.03.2027, факт 37) и сверяет ссылки — «все формулы считают верно»; ловит именно съехавшие строки. check_parse.mjs читает файл настоящим разборщиком дашборда (lib/plan.ts, скомпилирован внутрь проекта — из /tmp не находит пакет xlsx): год 2027, 96 строк, 8 категорий по 12 месяцев, уровни верные, итог 13 671, строк с фактом 0. Оба прогона описаны в README.
Сверить формулу «Прогноз» с файлом 2026
В файле владельца строки «Прогноз» дают коэффициенты к факту 1.196 (март), 1.30 (апрель), 1.108 (май), 1.19 (июнь) — одинаковые по всем категориям внутри месяца, но в общее правило не складываются. Формула в файле 2027 взята по смыслу: темп месяца, продлённый до конца. Владелец пришлёт файл 2026 — сверить и при расхождении переписать.
В план добавлен текущий год и разница
✓ Под каждой строкой «план» теперь «2026» (факт того же месяца базового года: январь–сентябрь из 2026-го, октябрь–декабрь из 2025-го, этих месяцев 2026 ещё не было) и «план к 2026» в процентах — формулой, а не руками. Числа берутся из расчёта с уже применёнными правками (сентябрь приведён к полному месяцу, июль по КЦ закрыт медианой), иначе сравнение показывало бы дырки в данных, а не разницу. Попутно понадобилась правка дашборда: lib/plan.ts искал «факт» строго следующей строкой после «плана», а теперь между ними стоят справочные строки. Разборщик ищет «факт» в пределах блока категории. Это важно для «Перехода с рассылки (заявка)»: у него нет событий, факт берётся только из файла. Проверено экзаменом: подставили факт в файл и прочитали (7 и 9). По году разница: МОРС, КЦ АНКЕТА, Просмотрел прайс лист, КЦ АКТИВНОСТИ — 0%; КЦ ПОТЕНЦИАЛЬНЫЙ и СК +5%; «Загружал товары» +61% (план от темпа второго полугодия, а не от суммы года — категория росла внутри года с 7 до 49 в месяц). Итого 13 671 против 13 256 факта, +3%. Файл и страница /lab/pulscen-plan-lidov-2027 обновлены (200).
План 2027 = факт 2026 помесячно (правило переписано)
✓ Владелец 30.09: «сделай план следующего года идентичным результату этого — помесячно, не общей цифрой; октябрь–декабрь протяни по предыдущим месяцам». Сезонные профили, режимы базы и коэффициенты из расчёта убраны: план месяца = факт того же месяца 2026. Окт–дек протянуты средним июля–сентября 2026; строка «2026» там пустая, разница не считается. Январь–сентябрь разница ровно 0% во всех строках — проверено экзаменом. Итог 13 513 против 13 750 плана 2026. Оба экзамена зелёные, разборщик читает 96 строк / 8 категорий. Текст внутренней страницы переписан под новое правило, файл и страница выложены (200). Осталось решить владельцу: апрель по КЦ АКТИВНОСТИ = 395 при 225–250 в остальных месяцах — выброс одного месяца теперь стоит планом на апрель 2027.
готовS28 · S52 — Надёжность базы3/4
Бэкапы базы: снимок, проверка, хранение, тревога
✓ Крон 03:10 /usr/local/bin/pulse-backup.sh. Согласованный снимок sqlite3 .backup (не cp — живой файл с журналом WAL копировать нельзя), обязательная проверка quick_check, сжатие 2,2 ГБ → 324 МБ, хранение 7 дневных + 4 недельных, усечение журнала, тревога задачей в этот дашборд при неудаче. Восстановление проверено в тот же день: 204 722 события, 6 111 действий КЦ, 178 отчётов, quick_check ok. До 02.10 бэкапов не было вообще, хотя у пяти соседних проектов на этом же сервере крон стоял.
Авария 02.10: база восстановлена, потерь нет
✓ Повреждён сам файл базы (Rowid out of order, btreeInitPage error 11), запись падала, чтение работало. Пересборка через .dump дала хуже бэкапа (144 действия КЦ из 6 022) — повреждение село в эти таблицы. Подняли копию от 06:18 и перезалили файлы дня. Повреждённый набор сохранён в /tmp/broken-*, не удалён. Диск и ФС чистые. Записано в docs/DEPLOY.md и память pulscen-wal-corruption-incident.
РЕШЕНИЕ ВЛАДЕЛЬЦА: переезд на PostgreSQL или остаёмся на SQLite
Третьего раза ждать не стоит: бьётся дважды за три недели. Варианты. A) Переезд на PostgreSQL (на cfru уже работают пять экземпляров, есть куда). Prisma меняет провайдера, данные переносятся скриптом. Оценка 1–2 дня. Закрывает причину целиком: нет файла-журнала, нет контрольных точек, запись не зависит от долгих чтений. B) Остаёмся на SQLite и лечим симптомы: journal_size_limit, принудительные контрольные точки по расписанию, запрет внешних запросов к живой базе. Полдня работы, но риск остаётся — база 2,2 ГБ с тяжёлой аналитикой за пределами комфорта SQLite. Рекомендую A. Пока сделан B-минимум (бэкапы + усечение журнала), этого хватит, чтобы не потерять данные, но не чтобы не падать.
КЦ АКТИВНОСТИ: список из девяти типов владельца, «Смена адреса» и «Рассылки» включены
✓ Решение владельца 05.10: считаем ровно девять типов, «Смена адреса» и «Рассылки» входят («я всегда с ними считал»), диалоги ТГ/МАКС/WhatsApp не считаются. Явный список KC_ACTIVITY_GOALS вместо «всё кроме исключённых» — новые цели больше не просачиваются. Экзамен s41 переписан под решение: до выката 2/4 (экран 206/240, пересчёт 236/265), после 4/4. Выкачено со снимком базы. Август 236, сентябрь 265 при плане 269. Записано в память и docs/PLAN-RULES.md.
готовS29 · S53 — Один лид на весь дашборд0/2
Лиды только трёх видов во всех разделах — готово локально, ждёт «да» на прод
✓ Решение владельца 07.10. Правило в одном месте — общий пул (lib/leadTypes.ts + computeAllEvents): девять событий, КЦ из действий по девяти типам, регистранты из РЕГИ. Найдено и исправлено: пул отдавал все типы; «Обзор» мешал КЦ по правилу «любая цель» (270 против 265 в плане); воронка считала КЦ как «всё кроме потенциального»; остальные разделы видели КЦ только из файла событий (53 клиента вместо 265); чат с ИИ читал события в обход пула. Экзамен S53: прод 2/8 → стенд 8/8; S41 4/4, S45 13/13, S47 9/9. План месяца не сдвинулся. Лидов: август 1 432 → 1 228, сентябрь 1 394 → 1 232. Поймана до выката регрессия: счета клиента лежат на всех событиях — у продавца пустели «Счёт был/стал»; разведено getAttributeEvents, сверка 4 754 строки, расхождений 0. Доказательства — docs/ACCEPTANCE-S53.md.
Счета из CRM: экзамен S46 падает и на проде (не регрессия S53)
6/10 на проде со старым кодом. В окне ночной тяги счета от пяти разных выгрузок — отменённые счета прошлых тяг не убираются; 13 счетов из файла владельца от 24.09 пропали (1,8% при допуске 1%); 2 расхождения ид сайта/клиента. Похоже на последствие простоя CRM 27.09–05.10 и ручных дотяжек. Проверка: node tests/spec/s46-bills.mjs с PULSE_URL прода. Риск: у продавца может висеть долг по отменённым счетам.
готовS30 · S54 — Загрузки дополняют, а не стирают0/0
задач нет
готовS31 · S55 — Карточка ПП: живые данные14/14
Цель: Кнопка «Обновить из Метрики» в карточке продавца ПП (свой сайт клиента) и срок пакета из CRM каждую ночь: оплатившие продление уходят из «Пакет заканчивается». docs/ACCEPTANCE-S55.md
Метрика сайта клиента в карточке ПП
Связка «сайт → счётчик» по домену из CRM и 17 аккаунтов Метрики, кнопка «Обновить из Метрики», год помесячно.
✓ Прод 09.10.2026 ~06:20 UTC, экзамен s55 23/23 на проде. По решению владельца: кнопка «Обновить из Метрики» в шапке, строки «Трафик сайта/Яндекс/Google/портал» из Метрики + столбики по месяцам с текущим месяцем; Excel и списки с новыми цифрами. Связка 1 509 сайтов.
А1 связка в базе, пересборка раз в неделю, загрузка дополняет
✓ Стенд на снимке боевой базы 09.10, экзамен s55 15/15. Прод 09.10.2026 ~06:20 UTC, экзамен s55 23/23 на проде. 1 508 связок; загрузка одной не стёрла остальные (1 508).
А2 кнопка: визиты, посетители, просмотры, отказы, источники, год по месяцам, дата
✓ Стенд на снимке боевой базы 09.10, экзамен s55 15/15. Прод 09.10.2026 ~06:20 UTC, экзамен s55 23/23 на проде. 9401059: сентябрь 9 259 визитов, Яндекс 843, Google 5 044, портал 61; 12 полных месяцев; дата видна.
А3 цифры равны Метрике
✓ Стенд на снимке боевой базы 09.10, экзамен s55 15/15. Прод 09.10.2026 ~06:20 UTC, экзамен s55 23/23 на проде. Карточка 9 259 = прямой запрос к Метрике 9 259.
А4 повторное обновление ничего не стирает
✓ Стенд на снимке боевой базы 09.10, экзамен s55 15/15. Прод 09.10.2026 ~06:20 UTC, экзамен s55 23/23 на проде. 13 месяцев на месте, полные месяцы не изменились.
А5 без счётчика: «Счётчика сайта в наших доступах нет», без кнопки
✓ Стенд на снимке боевой базы 09.10, экзамен s55 15/15. Прод 09.10.2026 ~06:20 UTC, экзамен s55 23/23 на проде. 99615846: строка есть, кнопки нет, ссылка «уточняется».
А6 сбой Метрики не ломает карточку
✓ Стенд на снимке боевой базы 09.10, экзамен s55 15/15. Прод 09.10.2026 ~06:20 UTC, экзамен s55 23/23 на проде. Ответ 502 с понятным текстом и прежними данными.
А7 после «Обновить» Excel карточки, реестр и «Пакет заканчивается» с новыми цифрами
✓ Прод 09.10.2026 ~06:20 UTC, экзамен s55 23/23 на проде. Реестр Яндекс 851 (metrika) = карточке; Excel карточки: подпись «Метрика сайта» и лист «Переходы по месяцам».
Срок и пакет из CRM каждую ночь
actual_packet_ends + конец оплаченного лота + платный пакет; поверх файла только при оплаченном продлении.
✓ Прод 09.10.2026 ~06:20 UTC, экзамен s55 23/23 на проде. Сроки 20 140 сайтов залиты; ночной daily.sh тянет шаг terms. 99748924 до 30.09.2027 вне блока, 98275458 в блоке.
Б7 ночная тяга берёт срок, оплаченный срок и пакет
✓ Стенд на снимке боевой базы 09.10, экзамен s55 15/15. Прод 09.10.2026 ~06:20 UTC, экзамен s55 23/23 на проде. 20 140 сайтов за 2 с; две опечатки в годе (20233) считаются пустыми.
Б8 срок CRM поверх файла только при оплаченном продлении
✓ Стенд на снимке боевой базы 09.10, экзамен s55 15/15. Прод 09.10.2026 ~06:20 UTC, экзамен s55 23/23 на проде. 200 оплаченных продлений; 33 выставленных без оплаты остаются со сроком файла.
Б9 оплатившие уходят из «Пакет заканчивается», неоплатившие остаются
✓ Стенд на снимке боевой базы 09.10, экзамен s55 15/15. Прод 09.10.2026 ~06:20 UTC, экзамен s55 23/23 на проде. 99748924 до 30.09.2027 и вне блока; 98275458 в блоке с 12.10.2026.
В10 фильтр «Счёт» и подпись смотрят на один счёт (событие или CRM)
✓ Прод 09.10.2026 ~06:20 UTC, экзамен s55 23/23 на проде. 4 796 строк с признаком, клиентов со счётом в «Без счёта» 0; СИБТЕХСНАБ-СВАРКА — оплачен (и продлён до 09.11.2027).
Прямая ссылка на карточку в дашборде продавца (/seller?site=)
Владелец 09.10: «я просил в дашборде продавца, а не ПП» — я дал ссылку на /pp/sites. Кнопка в карточке продавца уже на проде (та же карточка), проверено на проде.
✓ Прод 09.10.2026 ~09:00 UTC вместе с S56: /seller?site=<ид> открывает карточку с кнопкой «Обновить из Метрики».
готовS32 · S56 — Чат: честный ответ6/6
Цель: Владелец 09.10: «чат тупит, показывает регов 270 за сентябрь, а их 600+». Ответ называет отбор, чат не падает на непрофильниках, «закрепление» = закреплённый менеджер, город из основного региона. docs/ACCEPTANCE-S56.md
↑ Чат: честный ответ по регистрантам и отборам
277 было по ЦУ СО РОССИЯ, а ответ этого не говорил; «Не получилось обработать вопрос» = падение a.toLowerCase на «непрофильник = true»; город пуст у 517 из 624; отбор считал отклонённых (746 vs 624).
✓ Стенд (снимок 09.10): экзамен s56 10/10, прод старым кодом 2/10. Прод 09.10.2026 ~09:00 UTC: s56 10/10, живые вопросы через модель 4/4 (5 вызовов, ~0,5 ₽). S33 14/14, S34 17/17, S43 9/9 без изменений.
К1 ответ называет отбор («Регистранты (ЦУ: СО РОССИЯ) … 277»)
✓ Стенд (снимок 09.10): экзамен s56 10/10, прод старым кодом 2/10. Прод 09.10.2026 ~09:00 UTC: s56 10/10, живые вопросы через модель 4/4 (5 вызовов, ~0,5 ₽). Без отбора — «Регистранты … 624».
К2 сентябрь 624, сумма по ЦУ сходится, отбор клиентов = срезу
✓ Стенд (снимок 09.10): экзамен s56 10/10, прод старым кодом 2/10. Прод 09.10.2026 ~09:00 UTC: s56 10/10, живые вопросы через модель 4/4 (5 вызовов, ~0,5 ₽). 277+236+111=624; отбор 622 (два клиента с двумя сайтами), было 746.
К3/К6 непрофильник и не-текст в условии не валят чат
✓ Стенд (снимок 09.10): экзамен s56 10/10, прод старым кодом 2/10. Прод 09.10.2026 ~09:00 UTC: s56 10/10, живые вопросы через модель 4/4 (5 вызовов, ~0,5 ₽). true и «да» — 147 клиентов; число в условии — 200, не 500.
К4 «нет закрепления» = нет закреплённого менеджера
✓ Стенд (снимок 09.10): экзамен s56 10/10, прод старым кодом 2/10. Прод 09.10.2026 ~09:00 UTC: s56 10/10, живые вопросы через модель 4/4 (5 вызовов, ~0,5 ₽). СО (ЕК+ПМ), сентябрь: 15 клиентов; в воронке «закреплён за менеджером: нет».
К5 по городам «не указано» ≤ 10%
✓ Стенд (снимок 09.10): экзамен s56 10/10, прод старым кодом 2/10. Прод 09.10.2026 ~09:00 UTC: s56 10/10, живые вопросы через модель 4/4 (5 вызовов, ~0,5 ₽). СО РОССИЯ сентябрь: не указано 0 (было 222 из 277).
ревьюS33 · S57 — Дыры в данных: КЦ январь–май и приходы ПП май–июль 20267/10
Цель: Найдено при расчёте ГП 2027: КЦ янв–май 2026 без цели (нет в пуле, обзоре, плане), сырые приходы ПП май–04.08.2026 не загружены; выгрузка клиентов плана и «Сравнение» берут КЦ по kind. docs/ACCEPTANCE-S57.md
↑ Залить дыры: КЦ янв–май 2026 и приходы ПП май–июль 2026 из CRM; КЦ по цели везде
Тяга CRM тем же загрузчиком, что ночная (load-csv.mjs actions/payments). Код: kcPlanKind в planCalc, plan-clients и compareCatalog по цели. Копия базы prisma/dev.db.bak-s57-2026-10-13.
⛔ Сделано 7 из 8; К5 ждёт решения владельца по правилу дублей приходов (S58).
↑ К1 план янв–май 2026: КЦ из действий, сходится с CRM ±3
✓ Экзамен s57 К1 зелёный 13.10: источник actions, март 281/44, май в допуске от 365/47.
↑ К2 пул лидов янв–май 2026: КЦ есть и равен плану
✓ Экзамен s57 К2 зелёный: пул = строка плана по каждому месяцу.
↑ К3 действия КЦ янв–май без дублей по номеру
✓ Экзамен s57 К3: дублей 0 (заменено 916 ручных строк).
↑ К4 действия КЦ вне окна не тронуты
✓ Экзамен s57 К4: 2025-10..12 и 2026-06..09 как до починки.
↑ К5 ПП-приходы май–июль ≥98% строк CRM
⛔ Май 1149/1244, июнь 1355/1446, июль 1281/1532. Не загрузка: правило дублей paymentKey (клиент|дата|сумма|порядок|сайт) схлопывает разные лоты с одинаковой суммой — так вся история: ПП −2,7%/мес (1717,9 против 1765,0 млн за 2024-01..2026-10), НК сходится. Лечение — S58 (ключ с лотом + догрузка истории), решение владельца.
↑ К6 поток НК май–июль не поехал
✓ Экзамен s57 К6 зелёный: НК-клиенты и деньги как до (загрузчик пропустил все 133 строки НК).
↑ К7 остальные месяцы приходов не тронуты
✓ Экзамен s57 К7 зелёный; сверка 36 таблиц: ни одна не уменьшилась.
↑ К8 выгрузка клиентов плана за май = строке плана
✓ Экзамен s57 К8 зелёный (до починки 223/0 против 225/32).
↑ S58-кандидат: правило дублей приходов теряет ~2,7% денег ПП
paymentKey в lib/payments.ts без номера лота. Ключ с лотом из raw + догрузка CRM 2023-01..2026-10 (дополняет, ничего не стирает). Задевает «чек» ПП и суммы ПП по всей истории.
готовS34 · S59 — Передача клиентов продавца1/1
Цель: Владелец 15.10: клиенты Буньковой Н. → Матвиенко Н. в дашборде продавца ПП. Правило поверх файла портфеля (lib/ppManagerMoves.ts). docs/ACCEPTANCE-S59.md
↑ Бунькова Н. → Матвиенко Н. (137 сайтов)
✓ Стенд: s59 6/6 (Бунькова 0, Матвиенко 154, портфель 4 885, ЦУ Екатеринбург). Прод: экзамен старым кодом 2/6, выкат после «да». Прод 19.10.2026: s59 6/6.
готовS35 · S60 — Эксперименты-воронки12/12
Цель: 5 воронок регистранта со встречи 09.10 заведены в раздел «A/B-тесты» как эксперименты: шаги, база по месяцам, тест/контроль по чётным ID после запуска. Итоги экспериментов за 2,5 месяца к встрече 16.10.
Тип эксперимента «воронка»: расчёт и API
lib/funnelExperiments.ts, source='funnel' в /api/ab-tests, PATCH даты запуска. Спека docs/ACCEPTANCE-S60.md
✓ lib/funnelExperiments.ts + API (POST funnel, GET ?from, PATCH launchDate). ОТК: критик блокеров 0, «важно» 3 и мелочи исправлены, 20 граничных проверок сданы. Прод ждёт «да» Прод 19.10.2026: s60 39/39, 5 воронок заведены.
К1 В «A/B-тестах» 5 воронок с меткой «воронка» и статусом «не запущен», старые тесты на месте
✓ 5 воронок со статусом «не запущен», 2 теста Метрики на месте; локально (база 09.10), экзамен tests/spec/s60-funnel-experiments.mjs 39/39, прогон 15.10
К2 Карточка воронки: кого берём, гипотеза, механика, шаги, таблица по месяцам (шаги шт/%, НК за 92 дня)
✓ карточка: кого берём, гипотеза, механика, шаги, таблица по месяцам; снимок 1440 проверен глазами; локально (база 09.10), экзамен tests/spec/s60-funnel-experiments.mjs 39/39, прогон 15.10
К3 Цифры совпадают с независимым пересчётом по /api/events и /api/pay-map до штуки (янв–июл)
✓ все 5 воронок янв–июл совпали с независимым пересчётом до штуки (каталог 4337/1614/49/20/НК 51); локально (база 09.10), экзамен tests/spec/s60-funnel-experiments.mjs 39/39, прогон 15.10
К4 База «Каталога в рубрике» совпадает с разбором 09.10 в допуске
✓ каталог: 4337 рег, анкета 37,2%, товары 1,13%, прайс 0,46%, НК 1,18% — в допуске разбора 09.10; локально (база 09.10), экзамен tests/spec/s60-funnel-experiments.mjs 39/39, прогон 15.10
К5 Незрелые месяцы помечены «зреет»
✓ октябрь зреет, январь созрел, «зреет» ровно там, где окно не закрылось; локально (база 09.10), экзамен tests/spec/s60-funnel-experiments.mjs 39/39, прогон 15.10
К6 Дата запуска делит поток на тест (чётные ID) и контроль (нечётные), снятие возвращает «не запущен»
✓ запуск 01.06: тест 1226 / контроль 1251 = пересчёт; снятие даты → planned; проверено и в UI; локально (база 09.10), экзамен tests/spec/s60-funnel-experiments.mjs 39/39, прогон 15.10
К7 Новую воронку можно завести из интерфейса из пресета
✓ форма: источник «Воронка регистранта», 5 пресетов, дата запуска; снимок проверен
К8 /ab-tests и карточки открываются без ошибок на 1440 и 400
✓ 1440: список и карточка без ошибок приложения (в консоли только скрипт Касперского). 400: страница открывается, но боковое меню на всю ширину — общая вёрстка дашборда, не S60
Карточка воронки и создание из интерфейса
components/AbTestsClient.tsx: метка «воронка», статус «не запущен», таблица по месяцам, тест/контроль, форма с пресетами
✓ components/FunnelExperiment.tsx, AbTestsClient: метка, статус, база (6 созревших мес), тест/контроль, форма. Заодно починен ряд «Страницы теста» (w-full+w-28). Прод ждёт «да» Прод 19.10.2026: s60 39/39, 5 воронок заведены.
Завести 5 воронок (локально, на прод по «да»)
scripts/seed-funnel-experiments.mjs, идемпотентно по названию
✓ локально заведены, повтор ничего не дублирует; на проде после выката Прод 19.10.2026: s60 39/39, 5 воронок заведены.
Итоги экспериментов за 2,5 месяца к встрече 16.10
Список экспериментов из встреч/переписки/дашборда с результатами, документ Денису
✓ Downloads/ПЦ - итоги экспериментов 16.10.2026.pdf (исходник C:/tmp/pc-2to4/itogi.html); инвентарь 34 экспериментов C:/tmp/pc-2to4/eksperimenty-inventar-2026-10-15.md
готовS36 · S61 — Дашборд продавца: сроки и счета из пакетных лотов9/10
Цель: Письма продавцов/РОПов 15–16.10: срок пакета и «счёт был/стал» по пакетным лотам CRM (без медийки), оплаты по сайту, копирование ИД, ЦУ в шапке. docs/ACCEPTANCE-S61.md
↑ Сроки и счета «был/стал» из пакетных лотов CRM
✓ Стенд 16.10: s61 14/14 (прод старым кодом 4/14), 15/15 случайных сайтов = CRM. Прод — после «да». Прод 19.10.2026: s61 14/14, сроки 10 686 сайтов залиты.
К1 Глобал Драйв до 17.10.2026, продление 362 700 не оплачено
✓ Стенд 16.10: s61 14/14 (прод старым кодом 4/14), 15/15 случайных сайтов = CRM. Прод — после «да». в ближайших, 0 дней Прод 19.10.2026: s61 14/14, сроки 10 686 сайтов залиты.
К2 GGstroymarket до 18.05.2027, без медийки
✓ Стенд 16.10: s61 14/14 (прод старым кодом 4/14), 15/15 случайных сайтов = CRM. Прод — после «да». был 244 300 Прод 19.10.2026: s61 14/14, сроки 10 686 сайтов залиты.
К3 АбсолютКомплект 100 100 → 109 900
✓ Стенд 16.10: s61 14/14 (прод старым кодом 4/14), 15/15 случайных сайтов = CRM. Прод — после «да». как в CRM Прод 19.10.2026: s61 14/14, сроки 10 686 сайтов залиты.
К4–К5 медийных счетов в строках нет
✓ Стенд 16.10: s61 14/14 (прод старым кодом 4/14), 15/15 случайных сайтов = CRM. Прод — после «да». было 315 строк Прод 19.10.2026: s61 14/14, сроки 10 686 сайтов залиты.
К7 частичная оплата: долг виден
✓ Стенд 16.10: s61 14/14 (прод старым кодом 4/14), 15/15 случайных сайтов = CRM. Прод — после «да». 143 строки Прод 19.10.2026: s61 14/14, сроки 10 686 сайтов залиты.
К8 копирование ИД без https
✓ Стенд 16.10: s61 14/14 (прод старым кодом 4/14), 15/15 случайных сайтов = CRM. Прод — после «да». execCommand Прод 19.10.2026: s61 14/14, сроки 10 686 сайтов залиты.
К9 ЦУ в шапке и «Все продавцы ЦУ»
✓ Стенд 16.10: s61 14/14 (прод старым кодом 4/14), 15/15 случайных сайтов = CRM. Прод — после «да». Новосибирск 450 строк Прод 19.10.2026: s61 14/14, сроки 10 686 сайтов залиты.
К10 15 случайных сайтов = CRM
✓ Стенд 16.10: s61 14/14 (прод старым кодом 4/14), 15/15 случайных сайтов = CRM. Прод — после «да». 15/15 Прод 19.10.2026: s61 14/14, сроки 10 686 сайтов залиты.
↑ Разобрать сдвиг факта плана после S57 (S47 7/9, S49 3/4)
После выката 19.10 на проде: август «Просмотрел прайс лист» 335 вместо 334 (итог 1078 вместо 1077); факт окт-2025 «Загружал товары» 13 вместо 30 (план окт-2026 = 30). События в копиях базы 09.10 и 19.10 одинаковые — сдвиг деления НК/ПП при подсчёте, вероятно от оплат ПП май–авг, залитых в S57 13.10. Проверка: ssh cfru, cd /opt/pulse-analytics, node tests/spec/s47-plan.mjs и s49-plan-next.mjs с PULSE_AUTH из .env. Копии: /opt/backups/pulse-analytics/pre-s56-20261009-0857.db.gz и pre-s61-20261019-0659.db.
готовS37 · S62 — Связка сайтов с Метрикой из файла CRM1/1
Цель: Файл 21.10.2026_clients_report.csv (ид сайта → домен) → связка со счётчиками 17 аккаунтов; обновление по кнопке. docs/ACCEPTANCE-S62.md
↑ Загрузить связку из файла CRM, приоритет над company_sites
✓ Прод 22.10: связок 4 884 (файл 3 847), портфель ПП 3 540/4 885 (72%, было 486); кнопка на 2 новых карточках работает; S55 23/23.
ревьюS38 · S63 — Регистранты по инструкции аналитика3/4
Цель: Владелец 23.10: «сделай по их инструкции точь-в-точь». Регистрант = Принята + «для ведения в срм», причины (Закупки, Дубли…), франшиза отдельно, сводник по модерации и по 18 территориям как в их таблице. Эталон — их «Сводник по Модерации 26 ГОД».
↑ Ночная тяга регистрантов: критерии БП_КЦ Закупки и БП_Дубль из CRM
как 0П_Непрофильник (company_criteria)
✓ На стенде: registrants.sql отдаёт БП_КЦ Закупки, БП_Дубль, Тестовая компания, менеджера пакетных продаж; daily.sh снимает прошлый месяц 1–3 числа и дальше его не трогает. На прод ждёт «да». ПРОД 23.10 08:32 UTC: копия pre-s63-20261023-0832.db, миграция 20261023100000_regi_instruction, январь–сентябрь дотянуты --fill, октябрь обычной тягой. Экзамены на проде: S63 18/18, S40 5/5, S56 10/10, S33 14/14, S43 9/9, S34 17/17, S59 6/6, S61 14/14, S55 23/23.
↑ Перетянуть январь–июль 2026 из CRM со всеми статусами
сейчас янв–июн только «Принята» (очищенный мастер), июль неполный (638 против 686)
✓ На стенде: январь–сентябрь дотянуты режимом --fill (снимок статусов не тронут), октябрь обычной тягой. Строк ровно как у аналитика «всего с франшизой»: 708/828/1111/927/809/851/888/808/830. На прод ждёт «да». ПРОД 23.10 08:32 UTC: копия pre-s63-20261023-0832.db, миграция 20261023100000_regi_instruction, январь–сентябрь дотянуты --fill, октябрь обычной тягой. Экзамены на проде: S63 18/18, S40 5/5, S56 10/10, S33 14/14, S43 9/9, S34 17/17, S59 6/6, S61 14/14, S55 23/23.
↑ Правило регистранта и сводник по модерации как у аналитика
калибровка 23.10: Принята+ведения сходится помесячно (кроме июля)
✓ Экзамен s63 18/18 на стенде. Принята+ведения: 533/530, 599/601, 799/799, 734/730, 654/653, 671/672, 682/686, 620/620, 680/678. Сводник в разделе «Регистранты», Excel. Регресс S33/S34/S40/S43/S55/S56/S59/S61 зелёный (S40 приведён к новому правилу). На прод ждёт «да». ПРОД 23.10 08:32 UTC: копия pre-s63-20261023-0832.db, миграция 20261023100000_regi_instruction, январь–сентябрь дотянуты --fill, октябрь обычной тягой. Экзамены на проде: S63 18/18, S40 5/5, S56 10/10, S33 14/14, S43 9/9, S34 17/17, S59 6/6, S61 14/14, S55 23/23.
↑ Территории как у аналитика (18 территорий, 4 группы)
ЖДЁТ файл «Территории и ЦУ»: в CRM привязки регион→территория нет; без файла Казань 21 vs 63, Новосибирск 19 vs 54
✓ Справочник регион→ЦУ НК из её августовского файла (109 регионов, в CRM привязки нет). Август до штуки по 16 территориям, январь до штуки, остальные в допуске 12%. 230 регистрантов за год разнесены по стране — закроет её файл «Территории и ЦУ». На проде. Ждёт файл «Территории и ЦУ» от аналитика для 230 регистрантов, разнесённых по стране.
В РАБОТЕS39 · S64 — Чат с ИИ: лиды как в ГП, медийка, график0/4
Цель: Владелец 26.10: «чекни ИИ в дашборде, опять косяки». Разбор двух живых разговоров 26.10: «лиды по отделам» чат считал регистрантами (за 2025 «данных нет»), «медийку НК» — баннерами в деньгах отдела НК (33 кл / 1,03 млн вместо 2 кл / 204 500 за 2026), сортировка по месяцу шла по величине, графика нет.
↑ Набор «Лиды» (ГЛ/ТЛ) по правилам ГП
горячие: МОРС, загрузка товаров, КЦ потенциальный; тёплые: анкета, прайс, СК, КЦ активный; ГЛ∩ТЛ в месяце = ГЛ; ЦУ клиента; франшиза вне
✓ Стенд: лиды по правилам ГП, сверка с gp_result.json — 2025 и 2026 янв–сен по сети все 36 точек в 5%, отделы 2026 в 8%. Разбивка до трёх признаков. На прод ждёт «да».
↑ Набор «Медийка»: оплаты на ЦУ «(мод)»
баннер + внешний трафик; признак «клиент НК» и месяц, когда стал НК
✓ Стенд: оплаты на ЦУ «(мод)», признак НК; ставших НК в 2026 и купивших медийку 2 клиента / 204 500 ₽ (было 33 / 1,03 млн). Сумма 2026 сверится на проде (копия 23.10: 139,3 млн). На прод ждёт «да».
↑ Сортировка по разрезу и график по месяцам в ответе
sort.by=month шёл по величине; в ответе только таблица
✓ Стенд: «по месяцу» — календарь внутри ЦУ; линии по времени над таблицей, круглая шкала, проверено глазами. На прод ждёт «да».
↑ Дотянуть историю: действия КЦ 2024–2025-09, регистранты 2024–2025
без КЦ горячие лиды 2025 занижены; регистрантов до 2026 в базе нет
✓ Стенд: КЦ 2024-01..2025-09 и регистранты 2024–2025 из CRM. 21.08.2025 — массовый перенос 1 495 сайтов «для ведения в срм», вынесен в «Перенос в срм» (порог 100/день, ждёт решения владельца). На прод ждёт «да».
Ворклог (места остановки)
26.10.2026, 10:55:27 · · claude
S64 чат с ИИ: разобрал живые разговоры 26.10. Лиды теперь как в ГП (было — регистранты), медийка отдельным набором (было — баннеры отдела НК), сортировка по месяцу, график в ответе, разбивка до трёх признаков; история КЦ 2024–2025-09 и регистранты 2024–2025. Стенд: S64 9/10 (10-й — сумма медийки, только на проде), регресс зелёный.
→ Выкат по «да» + backfill actions 2024-01..2025-09 и registrants 2024-01..2025-12 на проде. Платный прогон s64-llm-replay по «ок». Решение по порогу массового переноса.
23.10.2026, 08:38:50 · · claude
S63 выкачен на прод 23.10: регистранты = Принята + для ведения в срм, без франшизы и холодных баз; сводник по модерации и территории в разделе «Регистранты»; ночная тяга снимает прошлый месяц 1–3 числа. Все экзамены на проде зелёные.
→ Файл «Территории и ЦУ» от аналитика. Проверка снимка октября 04.11.
23.10.2026, 08:28:52 · · claude
S63 регистранты по инструкции аналитика: все шаги инструкции нашлись в CRM (закупки, дубль, тест — критерии; «для ведения в срм» — название; франшиза — Беларусь + менеджер Франш2_Благинина; холодные базы — «ЛИД с ВЫСТАВКИ»). Сводник по модерации и территории в разделе «Регистранты». Стенд: экзамен 18/18, регресс зелёный.
→ Выкат на прод по «да»: миграция 20261023100000_regi_instruction, затем backfill.sh registrants 2026-01 2026-09 --fill, экзамен s63. Попросить у аналитика файл «Территории и ЦУ».
23.10.2026, 07:52:15 · · claude
23.10: сверка с инструкцией по регам (Google-таблица, лист «по регам» + «Сводник по Модерации 26 ГОД»). Сентябрь: у них 763 всего / 678 «Принята + для ведения в срм» / 677 для конверсий; у нас 764 / 624. Разница — 60 сайтов «для ведения в срм» (у нас 53 Отклонена + 5 Удалено отпадают), Закупки (28, у нас 6 в Принята считаются), статус на момент выгрузки; ЦУ у них 4 группы (СО Бойдова, Москва, Новосибирск, СО Ощепкова) против наших 3. По их правилу у нас вышло бы ~676.
→ Решение владельца: принять правило регистранта из инструкции (Принята + «для ведения в срм» − Закупки) и 4 группы ЦУ; нужен актуальный файл «Территории и ЦУ».
22.10.2026, 05:28:54 · S62 — Связка сайтов с Метрикой из файла CRM · claude
22.10: по «загружай» связка из файла CRM загружена на прод. Портфель ПП со счётчиком 3 540 из 4 885 (было 486). Автоматики нет (решение владельца), обновление по кнопке. Еженедельная пересборка берёт файл crm-pull/clients-report.csv первым.
→ Новый файл связки класть в crm-pull/clients-report.csv. Остальное: просроченные без оплаты наверх «Пакет заканчивается» ждёт «да»; S47/S49 дрейф; S58.
22.10.2026, 05:05:24 · · claude
22.10: разбор файла 21.10.2026_clients_report.csv (ид сайта → домен сайта на портале, 7 969 строк). Со счётчиками 17 наших аккаунтов связывается 3 514 из 4 885 сайтов портфеля ПП (72%, сейчас 486): 3 322 по домену сайта, 519 витрин-поддоменов pulscen.ru. Сверка 8 сайтов за август: Яндекс и Google близки к файлу «Аналитика для продаж», трафик сайта и портал в Метрике ниже (портал считает часть своего внутреннего трафика).
→ «Да» владельца → загрузить связку в SiteCounter (новый источник, приоритет над доменом из CRM), затем решить про ночное обновление Яндекс/Google для всех связанных.
20.10.2026, 10:19:00 · · claude
Блог ПЦ партия 4 (10 статей): «ок» владельца 20.10. Файлы для редактора готовы: Загрузки/Статьи ПЦ/ПЦ4_*.html и ПЦ4_статьи_партия_4.zip.
→ Владелец передаёт архив редактору. Через неделю сверить живой блог Playwright'ом: какие из 10 вышли и что редактор поправил.
20.10.2026, 08:43:15 · · claude
20.10 блог ПЦ: партия 3 вся на сайте (10/10, проверено по живому блогу). Партия 4 (10 статей) написана: 6 для покупателя (запрос КП, как найти поставщика, упаковка, новогодние подарки, спецодежда, уголь оптом) и 4 для продавца с квизом (отсрочка платежа, дилер и дистрибьютор, план продаж, контрактное производство). У каждой своя структура и голос, проверка правил редактора и шаблонности check_content4.py + check_pc4.py 0 ошибок. Превью myvisionagency.ru/lab/pulscen-statyi-4/, файлы редактору Загрузки/Статьи ПЦ/ПЦ4_* + zip.
→ После «ок» владельца отдать файлы редактору ПЦ. Следующая партия — когда редактор выложит половину четвёртой.
19.10.2026, 07:11:20 · · claude
19.10: по «да» выкачены S59 (Бунькова→Матвиенко), S60 (воронки-эксперименты), S61 (сроки и счета из пакетных лотов). Копия базы pre-s61-20261019-0659.db. Экзамены на проде: S61 14/14, S59 6/6, S60 39/39, S55 23/23, S56 10/10, чат 14/17/9 зелёные. S47 7/9 и S49 3/4 — дрейф сегментации НК/ПП после данных S57 (13.10), события в базе не менялись (сверка копий 09.10 и 19.10).
→ Разобрать S47/S49: факт октября 2025 «Загружал товары» 30→13 при тех же событиях; вопрос Наталье про пакеты на медийном ЦУ; S58 ждёт «да».
16.10.2026, 12:55:22 · S61 — Дашборд продавца: сроки и счета из пакетных лотов · claude
16.10: разбор писем продавцов ПП. Причина почти всего — срок из поля CRM «конец пакета» (сдвигается при выставлении продления, ловит медийку) и счета из событий НК / последнего счёта клиента. Переделано на пакетные лоты по сайту (правило Натальи), медийный ЦУ исключён. Копирование ИД, ЦУ в шапке. Метрика с 16.10 отвечает 400 на любой запрос (Яндекс).
→ «Да» на выкат S59+S60+S61 одним разом (миграция S61 при остановленном приложении). Вопрос Наталье про пакеты на медийном ЦУ (51 лот).
15.10.2026, 11:09:52 · S60 · claude
S60 «Эксперименты-воронки»: тип эксперимента funnel, 5 воронок со встречи 09.10 в «A/B-тестах», база 6 созревших мес, тест/контроль по чётности ID. Экзамен 39/39, ОТК критик (0 блокеров, правки внесены), 20 граничных проверок. Итоги экспериментов Денису PDF.
→ Ждёт «да» на прод: выкатить ТОЛЬКО файлы S60 (на проде нет S59), build, pm2 restart, seed, экзамен на проде. Вопросы владельцу: РК ЕКБ, непрофильники, подсказки.
15.10.2026, 08:18:58 · S59 — Передача клиентов продавца · claude
15.10: передача клиентов Буньковой Н. Матвиенко Н. правилом поверх файла «Аналитика для продаж»; стенд 6/6.
→ «Да» владельца → выкат (без миграций).
13.10.2026, 05:08:03 · 99d5ed92-4921-4d81-ae42-2074485c271e · claude
S57: залиты дыры данных по «да» владельца. Код (kcPlanKind; выгрузка клиентов плана и «Сравнение» берут КЦ по цели) выкачен, сборка ок. Из CRM: действия КЦ 01.01–31.05.2026 (2218, заменено 916 ручных), приходы ПП 01.05–04.08.2026 (принято 3815). Сверка 36 таблиц: ничего не уменьшилось, quick_check ok. Экзамен s57: 7/8.
→ К5 красный из-за давнего правила дублей приходов (ПП −2,7%/мес ≈ 47 млн за 2024–2026). Ждёт «да» на S58: ключ с номером лота + догрузка истории. Ещё решить судьбу 1155 старых ручных действий КЦ без цели.
09.10.2026, 09:04:47 · S56 — Чат: честный ответ · claude
09.10: по «выкатывай и прогоняй» выкачены S56 (чат: отбор в ответе, непрофильник, закрепление, город, отклонённые не регистранты) и ссылка /seller?site=. Прод: s56 10/10, s55 23/23, чат s33/s34/s43 без изменений. Живой прогон 5 вопросов через модель 4/4 (~0,5 ₽), тестовые сессии удалены.
→ Мелочь: «Подошло 1 клиент» → «Подошёл». Проверка по сроку 14.10 (weekly Метрика + ночные сроки). Решение владельца по 38 «кончился раньше файла».
09.10.2026, 08:42:53 · S56 — Чат: честный ответ · claude
09.10: разбор чата по жалобе «270 регов за сентябрь». Сегодня вопросов не было; 277 — ответ 07.10 по одному ЦУ без указания ЦУ. Найдены и исправлены на стенде: отбор не назван в ответе; падение на «непрофильник» (2 вопроса 08.10 и 1 07.10); город пуст у 83% регистрантов; отбор клиентов считал отклонённые сайты; «нет закрепления» подменялось «не взят в работу». Экзамен S56 10/10 на стенде (прод 2/10).
→ «Да» владельца → выкат S56 вместе со ссылкой /seller?site= (без миграций). «Ок» на платный прогон 3–5 живых вопросов через модель (~0,5 ₽).
09.10.2026, 06:37:39 · S55 — Карточка ПП: живые данные · claude
09.10: владелец поправил — смотреть надо в дашборде продавца (/seller), а не в ПП. Проверил на проде: кнопка «Обновить из Метрики» в карточке продавца есть (та же карточка, светлая тема в порядке). Собрал на стенде прямую ссылку /seller?site=<ид>.
→ «Да» владельца → выкат ссылки /seller?site= (без миграций). Проверка по сроку 14.10.
09.10.2026, 06:26:45 · S55 — Карточка ПП: живые данные · claude
09.10: по «да» владельца S55 выкачен на прод в виде, который он описал: кнопка «Обновить из Метрики» в шапке карточки, существующие строки трафика (сайт, Яндекс, Google, портал) из Метрики сайта + столбики по месяцам с текущим, Excel/списки с новыми цифрами, прямая ссылка /pp/sites?site=. Починен фильтр «Счёт» (CRM-счёт стоял в «Без счёта»). Срок пакета из CRM по оплаченному продлению. Экзамен 23/23 на проде, соседние без изменений. Крон weekly добавлен.
→ Владелец смотрит карточку по ссылке. Проверка по сроку 14.10 (weekly + ночные сроки). Решения: 38 «кончился раньше файла»; формула файла (витрина) против Метрики сайта.
09.10.2026, 05:39:03 · S55 — Карточка ПП: живые данные · claude
09.10: S55 собран и проверен на стенде (снимок боевой базы 09.10). Кнопка «Обновить из Метрики» в карточке ПП (свой сайт клиента, 486 из 4 885 сайтов портфеля), срок пакета из CRM по оплаченному продлению. Экзамен s55: прод 0/11, стенд 15/15; соседние S41/S45/S47/S49/S53 без изменений, S46 6/10 как на проде. Найдено: трафик в файле «Аналитика для продаж» = витрина на портале, Метрикой его не повторить; 33 продления выставлены без оплаты; 38 сайтов, где CRM говорит «кончился раньше файла».
→ «Да» владельца на прод → pm2 stop, две миграции, сборка, старт → weekly.sh + сроки руками → экзамен s55 на проде → крон weekly → проверка по сроку 14.10 (недельная пересборка отработала). Решения владельца: 38 «кончился раньше», витрина vs свой сайт.
07.10.2026, 13:34:06 · · claude
Ночная смена 07→08.10: для Ольги собран расход Контент завода по месяцам (кабинет работал фев–апр 2026: 6 942 / 11 562 / 4 495 ₽, итого 22 999 ₽, 309 роликов; с мая 0; два пополнения зачислены админом вручную) — C:/tmp/pc-zavod-rashod/. Черновик плана лидов 2027 по каналам (C:/tmp/pc-plan-2027/plan-lidov-2027.md): факт 2026 по кварталам, бренд = 346 из 347 заявок, 144 513 ₽ за 9 мес. в кампаниях без заявок, 3 сценария; дополняет /lab/pulscen-plan-lidov-2027/ от 29.09.
→ Владелец: ответить Ольге (вопрос про два ручных пополнения), отправить Денису черновик из раздела 5; на встрече 12.10 поднять паузу «Отвалы»/«МСК»/«Система роста» и защиту бюджетов 19–23.10. Порт 21122 к базе Тюльпана закрыт с 27.09 — ночная тяга дашборда стоит, нужен Семён/Казаков. Замер конверсии вебинара после 14.10.
07.10.2026, 06:58:21 · S54 · Клод
Владелец 07.10: «чтобы ничего не стиралось, а только дополнялось». Аудит всех загрузок: стирали целиком статистика ПП (ЦД и переходы), план («одиночка» — 2027 стёр бы 2026), справочник «город → ЦУ», отвалы. Все переведены на «заменить только то, что в файле». Неполный текущий месяц статистики ПП пропускается (в файле трафика была неделя октября). Кэш «Плана» и «Обзора» привязан к версии данных. Выкачено со снимком базы. Файлы владельца залиты: статистика ПП 14 месяцев, 12 прежних не тронуты, 8 карточек сверены. Попутно: план Q4 2026 по КЦ АКТИВНОСТИ пересчитан по правилу девяти типов (282/247/224 вместо 264/234/206). Экзамены на проде: S41 4/4, S45 13/13, S47 9/9, S49 4/4, S53 8/8.
→ 1) Счета из CRM: S46 6/10 — отменённые счета прошлых тяг не убираются. 2) «СК» с «Выбором шаблона» или без — вопрос владельцу. 3) Сверка свода правил docs/PLAN-RULES.md владельцем. 4) Блок Метрики в карточке — ждёт решения.