Вторую редакцию проверили трое: двое ворот вслепую и судья. Оба проверяющих
работали по спеке, план им был запрещён словами, оба отчитались «план не
открывал» и оба назвали вещи, которых в плане нет. Судья план читал и искал
ошибки надзирателя.
Проверено командой: план 2801 строка / 19 разделов / 46 задач, спека 2126 / 18 /
96 требований, протокол 2150 / 7 / 72 решения. Разметка чистая во всех трёх.
Полный прогон: 4755 из 4760, упавший тест чужой (коммит 1ed82b6b3), в одиночку
файл проходит 10 из 10 — грязь от соседнего теста, не поломка продукта.
Шесть ошибок надзирателя, найденных судьёй, все настоящие:
- план утверждал, что приёмщица живёт в отдельной папке bots/lena-vhodyashchie —
такой папки нет, это тот же most.py вторым процессом. Заходов в мост стало
семь, порядок в таблице горл исправлен;
- наставления робота лежат вне репозитория, задачи на это не было — З-0.7;
- Т13, Т23, Т24 не были поручены никому, все три про то, что робот говорит
вслух — З-4.8;
- своя очередь и живое обновление экрана выброшены целиком — З-6.8;
- проверка дословности каркаса и три проверки манеры проходили при сломанной
работе — переписаны;
- порядок по узким горлам врал в пяти местах; З-2.4 обещала поле в карточке
сделки, не назвав ни одного файла экрана.
Улов ворот, внесённый в план и в новый §18 спеки:
- стирание по требованию человека не достаёт до звука и расшифровки: сделка
стёрта, голос остался — З-2.5;
- безопасный ритм 40-100 наборов в день на номер измерен нами же, Т38 перебивает
его в разы; счёт попыток не привязан к человеку — до 24 наборов за двое
суток — З-3.8;
- дорезерв на ходу Т60 не сработает ни разу: заморозка не складывается;
- реклама физически не возвращается — состояние тупиковое, ручка ждёт другого
состояния; письмо обещает невозможное;
- замкнутый круг: обзвон морозит деньги, списание тушит Директ, тушение отпускает
бронь рекламы, её доедает обзвон;
- проверка «наружу не ушло ничего» неисполнима — единого журнала исходящих нет;
- своё окно клиента ломает несущее правило часов «живёт здесь и больше нигде»;
- робот не слушается скрипта — измерено, а вся защита проверяется по тексту
скрипта; проверки переведены на запись разговора;
- этикетка на экране у человека — чужого юрлица ООО Лизинговая Омега;
- трансграничная передача голоса: в 96 требованиях ни слова.
Два решения владельца, принятых по ходу проверки:
- Р71 арендуем двенадцать номеров, не десять — спор Р41 и Р53 закрыт. Замерено:
у оператора восемь номеров, докупить надо пять, а не двенадцать;
- Р72 у лидов, пришедших через нашу платформу, согласие уже есть — подтверждение
спрашиваем у двух источников из четырёх.
Замеры смены: номеров у оператора восемь, в телефонию заведено два, наружу
звоним одним; письмо о нехватке денег одно и боевое; на машине робота 13 ГБ
свободно, записей 68 МБ в 89 файлах, чистки нет.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
План 2026-08-04 писался, когда закрытых развилок было ноль. Сейчас закрыты 28 из 29,
и пометки «заблокировано развилкой» врали в обе стороны. Вторая редакция.
Было 32 задачи в шести волнах — стало 41 в семи. Проверено командой:
2292 строки, 18 разделов, 41 задача, разметка чистая, ссылок на файлы ноль.
Разблокировано решениями владельца: вход клиента Р66/Р67/Р60, окно часов Р64,
письма Р52, каркас и личная правка Р46, обратные звонки Р62/Р63/Р48/Р54,
запись менеджера Р61, замок Т31 Р57, источники получателей Р65.
Из семнадцати заблокированных задач не осталось ни одной запертой полностью.
Прибавилось:
- волна 5 «авто-обзвон» целиком — решение Р39, перенос измеренного устройства авто-СМС;
- З-0.5 обрыв на 60-й минуте и подсказка менеджеру на 55-й — Р43;
- З-1.7 письмо про обе остановки — Р56;
- З-3.6 подтверждение согласия при каждой загрузке — Р42;
- З-3.7 закрытые номера: тишина, счётчик, бесплатность — Р48, Р49;
- З-4.4 личная правка сильнее каркаса — Р46;
- З-4.5 манера живёт у робота — Р68;
- З-4.2 сборка скрипта машиной — найденная дыра: требование Т7 стоит в спеке
с первого дня, а задачи под него не было ни одной.
Переписано против первой редакции:
- стоп-лист — решение Р45 обратно прежней рекомендации: свой, пятый список;
- чистка — три ступени по одной строке вместо одной операции, Р50 и Р51;
- заморозка — два режима: авто по поступлению, база пачкой, Р39;
- отчёты — по людям, а не по наборам номера, Р47;
- З-2.4 первой редакции упразднена: Р50 сняло бессрочную обезличенную расшифровку.
Два места, где нужно слово владельца, оба всплыли после закрытия развилок:
1. Двенадцать попыток дозвона требуют двенадцати разных номеров Р53,
а арендовать решено десять Р41. Арифметически невыполнимо.
2. У авто-обзвона нет загрузки списка — к чему привязать подтверждение согласия,
не решено.
Спека выправлена шестью правками: освобождён задвоенный номер Т73 → Т98,
снята устаревшая бессрочная расшифровка, названо противоречие десяти и двенадцати
номеров в трёх местах. Требований 96, разделов 17, закрытых развилок 28.
Промт следующей смене заменяет прежний — очереди развилок больше нет.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Допрос по спеке «Обзвон» доведён до конца: 28 развилок закрыты решениями
владельца, одна (плата за второе плечо перевода) намеренно отложена до замера
цены звонка. Незаданных развилок не осталось — объявлено вслух.
Хранение и закон:
- Р50/Р51 — сроков два: звук месяц, текст три месяца, потом остаются сухие
итоги. Строку не удаляем: иначе нечем подтвердить счета за прошлые кварталы;
- Р52 — в письме менеджеру и номер, и ссылка на сделку (цена: наша чистка до
почтового ящика не дотягивается);
- Р59 — об удалении своих записей клиент узнаёт надписью на их месте;
- Р61 — менеджера клиента о записи не уведомляем.
Темп и защита:
- Р53 — шесть попыток в сутки, ровно два дня, всего до двенадцати;
- Р58 — три одновременные линии, больше только через нас (работает без замера);
- Р64 — часы менеджера задаёт клиент, и они только сужают общее окно.
Деньги:
- Р54 — обратный звонок после кампании идёт в долг, ничего не резервируем;
- Р55 — большой список запускать не мешаем, но последствие названо словами и
нужно подтверждение;
- Р56 — письмо о минусе называет обе остановки: обзвон и рекламу.
Вход и скрипт:
- Р66 — клиента без записей берём: стандартный каркас, наши вопросы, его сайт;
- Р60/Р67 — пятнадцать записей ориентир, список на входе один;
- Р65 — источников получателей три, как в рассылках; моё Т43 снято;
- Р62 — приёмщица одна, но представляется по сделке звонящего;
- Р68 — манера живёт у робота, а не в скрипте;
- Р69 — машина отдаёт скрипт сразу размеченным;
- Р70 — правку раскладывает руками тот, кто её принимает;
- Р63 — на своём номере отвечаем всегда, запрет второго перезвона снят.
Правило, выведенное по ходу и решившее часть вопросов само: надпись — там, где
клиент за свои деньги получает работу; замок — там, где работа гарантированно
бесполезна. Р18 про выбор, а выбора нет, когда результат предрешён.
Три слепых сторожа найдены и переписаны:
- проверка «манера во всех скриптах одинакова» проходила бы ровно при
расползании правки, то есть зеленела в момент беды;
- проверка «три клиента попросили одно и то же» считала буквальные совпадения
в свободном тексте, которых не бывает;
- Т70 всё ещё обещало шесть месяцев звука вместо принятого месяца.
Дыра, вскрытая ответом: минус на счету гасит клиенту весь Директ, а кто
включает рекламу обратно после пополнения — не задано ни одним решением.
Настоящий мобильный номер, попавший в протокол как название проекта, замаскирован.
В истории он остаётся (коммит 06f49ce0d) — вычищать историю ветки без владельца
не стал.
План под новые решения НЕ переписан: в нём 32 задачи с пометками
«заблокировано развилкой», расставленными до ответов. Стройку не начинать.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Раньше «Ниша» стояла только на «Воронке отдела». Теперь тот же фильтр есть
и на личном экране менеджера — он обзванивает подряд одну нишу, ему нужнее всех.
Список ниш у менеджера считается по ЕГО карточкам: сужение «только свои»
наложено раньше, поэтому чужая ниша в список не попадает, а ?rubric= не может
стать лазейкой к чужой воронке — на это есть отдельная проверка.
Поведение обоих экранов задаёт один кусок кода, composables/prospectRubricFilter.ts.
Двумя копиями «Без ниши последним» и самосброс исчезнувшей ниши разъехались бы
на первой же правке.
Проверено: Pest по продажам 525 зелёных, Vitest по фронту 2077 зелёных,
vue-tsc и Larastan чисто.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
План фичи «Обзвон» — 32 задачи в шести волнах, 17 помечены «заблокировано
развилкой», в конце таблица «развилка → сколько задач держит».
Ворота вслепую по плану, двое разными ходами (по требованиям подряд и «пройди
один рабочий день в бою»). Нашли то, чего не видели ни спека, ни надзиратель:
- заморозка денег под обзвон гасит клиенту рекламу: выключатель считает
«баланс не меньше замороженного», при нарушении слушатель тушит все кампании;
- перевод звонка — два плеча у оператора, а клиенту выставляется одно
соединение: чем чаще успешный перевод, тем хуже сходится экономика;
- обратный звонок сегодня попадает в наш собственный отдел продаж;
- «исход» означает две разные вещи — чем кончилась попытка и чем кончилась
работа с номером.
Развилок в спеке стало 29. Ни одна не разрешена — это решения владельца.
Новые решения владельца:
- Р39 — режимов обзвона два, морозим по-разному: авто-обзвон по поступлению
лида, обзвон базы пачкой. Владелец поймал вопросом ошибку в моей
рекомендации: спрятать заморозку от выключателя значило сделать минус
ежедневным, а резерв фикцией;
- Р40 — звук храним месяц, не полгода (правит Р22): место падает с ~50 ГБ
на клиента до ~8, а учит текст, а не звук;
- Р41 — пул номеров общий на портал, аренду платим мы. Чинит то, что сегодня
человек после робота перезванивает нашему отделу продаж.
Спека дополнена авто-обзвоном (Т33а–Т33е) и разведённой заморозкой
(Т58/Т58а/Т58б).
Поправка к прежнему докладу: тревога «записи положат портал» была ошибочной —
по чертежу звук лежит в облачном хранилище, а падение 29.05 было на другой
машине. Правдой осталось, что в хранилище сегодня не кладётся ничего.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Ниша едет из «Поиска клиентов» в карточку воронки: новая колонка
sales_prospects.rubric, приём ниши от службы поиска и из прогрева,
разовая проставка всех текущих карточек по ИНН / сайту / названию+городу.
Фильтр «Ниша» встаёт между «Менеджер» и «Происхождение»; список ниш
считает сервер по текущей выборке — с учётом менеджера, происхождения
и дат, но без учёта самой ниши. Пункт «Без ниши» — только когда такие
карточки есть. Исчезла выбранная ниша — фильтр сбрасывается сам и
говорит почему.
Своим карточкам нишу вписывают руками: подсказка по уже существующим,
опечатки и другой регистр приклеиваются к существующей молча, похожее
название подсказывается, но сохранить своё разрешено.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Дыра: golos-test/inostrannye/ содержала выгрузку «Записи разговоров» с 44 настоящими
номерами живых людей и не была в игноре — любой `git add .` затащил бы персональные
данные в историю навсегда. Закрыто правилом /golos-test/, проверено check-ignore.
Работа шла по docs/superpowers/METOD-vedeniya-fichi-v1.md (файл лежит в ветке
feat/night-dispatcher-part1): спека → ворота вслепую → правки чужой рукой → судья.
- спека фичи «Обзвон»: 72 требования, 18 развилок владельца намеренно не разрешены;
- приёмочный лист ворот написан ДО работы, а не после;
- протокол допроса: решение Р38 (счёт уходит в минус, долг остаётся за клиентом)
и поправка к приписке про экран СМС — путь к файлу был моей догадкой, а прочитан
следующими как слово владельца, и по нему ошиблись все трое.
Замеры смены: ворота вслепую двумя разными ходами дали 0 из 72 «умеет»; полный
прогон 4650 проверок, 4646 зелёных, красных ноль.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Бумаги затеи о ночном работнике, который делает работу по плану восемь часов
без человека, а утром присылает письмо владельцу.
Что лежит:
- бумага «что и зачем» (125 проверок, заморожена) и протокол допроса, 123 решения владельца
- разрез на семь кусков «тонкой нитью насквозь» и договор о стыках
- семь планов: куски 1-4 с кодом, куски 5-7 без кода (решение владельца 121)
- записи ворот, правщиков и сквозных ворот, 45 файлов
Порядок работы, отработавший впервые целиком: договор, трое пишущих разом,
ворота двумя углами на каждый план, правщик, СКВОЗНЫЕ ВОРОТА двумя углами,
правщик стыков.
Числа: 400 находок ворот за затею, из них 160 за 01.08, ложная одна.
Решение 121 (план без кода) проверено замером: планы вдесятеро короче прежних
при том же числе проверок, а находок не меньше — но смысловых вместо механических.
Сквозные ворота дали 25 находок, ложных ноль, и поймали класс, невидимый
изнутри одного плана: приёмка сносила рабочий угол под живым работником,
поднятым кнопкой «продолжить». Куски 6 и 7 не назвали друг друга ни разу.
Строк настоящего кода — ноль. Ночей отработано — ноль. Стройка не начиналась.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Просьба владельца 01.08.2026: «убери вчера, наверх создай просроченные,
сегодня, завтра и т.д. и проверь что они правильно привязаны и реально
работают»; во втором режиме «убери завтра — завтра у тебя не может быть».
У каждого режима теперь СВОЙ список сроков, они не пересекаются:
Что надо сделать (вперёд): Просроченные / Сегодня / Завтра /
Ближайшие 7 дней / Ближайшие 30 дней / Произвольный
Что менялось (назад): Сегодня / Вчера / 7 дней / 30 дней / Произвольный
Каждый пункт показывает ровно то, что на нём написано. Раньше просроченное
подмешивалось в ЛЮБОЙ выбранный период, и «Сегодня» показывало не только
сегодняшнее — теперь это отдельный первый пункт (period=overdue), а подпись
«плюс всё просроченное» убрана за ненадобностью.
Вторая, невидимая глазом поломка: «7/30 дней» в режиме планов считались
НАЗАД (d7/d30) — «что надо сделать за прошедшую неделю». Добавлены зеркала
next7/next30 в SalesPeriodResolver.
Срок из чужого набора («что менялось завтра») сервер отвергает с 422, а не
подменяет молча текущим месяцем, как делал прежний резолвер по умолчанию.
Проверено:
- сервер: 30/30 (фильтр + резолвер), весь отдел продаж 498/498;
- фронт: 1739/1739 весь набор;
- приёмка вырезанием — подложил поломку в оба места, оба набора покраснели;
- глазами в браузере 1920×1080: списки сроков в обоих режимах, «Просроченные»
дают ровно забытые карточки, «Завтра» — ровно завтрашнюю (скрины 08–12).
Попутно починен чужой протухший тест advertising-channels: Телеграм давно
стал живым роутом, а тест продолжал считать его заглушкой и был красным.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Стадию меняют два разных места — результат разговора менеджера и автопереезд
по деньгам. Джоба не оставляла следа вообще, поэтому «что менялось за день»
было не из чего построить. Запись движения перенесена в событие модели: один
шов на всех, включая любой будущий третий источник.
- sales_prospect_moves — журнал всех движений (append-only, с GRANT'ами ролям);
- prev_stage на карточке — откуда приехала (кормит счётчик «69/1» у «Отказа»);
- stage += 'trash' — место под колонку «Корзина».
Сторож проверен вырезанием: без записи движения краснеют 4 теста, в том числе
тест джобы и тест API.
Конфликты только в документах: журнал «мозга» взят из main, запись v9.28
переставлена поверх боевого журнала схемы. Код не пересекался.
Сторож слоёв проверен отдельно в рабочей папке: 0 нарушений.
Сторож секретов gitleaks отработал по-настоящему.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
В спеке §3 уточнено по факту кода: нормализатор отдаёт номер с плюсом,
а хранится он без плюса — плюс срезаем.
Сторожа орфографии и разметки пропущены: они не находят проблемы, а падают —
их библиотеки в корне обрезаны той же поломкой, что статанализ и сторож
журналов. Сторож секретов gitleaks — живой, работает.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Проверка ссылок падала на девяноста двух ошибках, поэтому любая отправка в main
шла через обход. Смысл починки не в красоте: пока ошибок девяносто две, новая
битая ссылка тонет среди них и никто её не замечает. Теперь ноль, и пуш проходит
обычным порядком.
Что было внутри девяноста двух:
68 — ссылка написана от корня хранилища, а документ лежит на две-три папки
вглубь. Приписаны шаги вверх. Файлы всё это время лежали на месте.
8 — файл существует, но переехал: Jobs/Billing, Jobs/Supplier, Services.
Адреса переписаны на нынешние места.
8 — файла нет и не будет: ProcessWebhookJob снят при уходе от старого
биллинга, SupplierCsvParser удалён 09.07 как мёртвый, каталог memory
уехал в claude-brain, а HANDOFF прогрева от 25.07 не существует ни
в одном коммите. Ссылки сняты, текст оставлен.
3 — неверное число шагов вверх: две точки вместо трёх.
3 — это вообще не ссылки, а примеры в тексте: http:// как образец мусорного
ввода, https://ваш-сайт.ru из подсказки формы. Обёрнуты в кавычки-код.
1 — адрес с приписанными номерами строк, которых проверятель не понимает.
1 — Россвязь. Сайт мёртв по-настоящему: сервер 194.226.91.2 отдаёт nginx-ову
404 на любой адрес, включая корень, а сертификат выписан не на это имя;
ведомство расформировано. Замену проверить не удалось — преемник
с этой машины не отвечает вовсе. Ссылка снята, адрес читается текстом.
Вопрос «где реестр нумерации живёт теперь» остаётся открытым.
Исключения проверятеля не тронуты ни на строку. Ноль получен починкой, а не
глушением сторожа — иначе вся работа теряет смысл.
Отдельным прибором проверено, что видимый читателю текст не изменился ни в одной
из 81 правленой строки: правились только адреса ссылок. Разметка линтером чистая.
Вместе с починкой ложится промт смены, по которому работа делалась.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Слияние feat/client-telegram-ads с main 8bdd58e8. Десять швов разобраны вручную:
денежный файл AdWalletService взят из main целиком — проверено поимённо, что все три
починки на месте: свой контекст клиента, оживление брони, таяние заморозки. В расписании
объединены оба набора заданий: телеграмные два и рекламные четыре. В боковом меню и в
мобильном «Ещё» сохранён пункт «Рекламный кошелёк», подписи поправлены — на реальные
экраны ведут ОБА канала. Словарь, пример настроек и журнал схемы объединены.
Сверх самого слияния:
- Журнал схемы: телеграмные записи v8.86-v8.95 перенумерованы в v9.18-v9.27, блок
переставлен наверх, пометки «номер предварительный» сняты и заменены одной врезкой
о перенумерации. Задвоенных номеров не осталось. Врезка шапки теперь называет и
телеграмные таблицы: их DDL, как и рекламный, живёт только в дельта-миграциях.
- Новый сторож денег tests/Feature/ClientTg/TgMoneyUnderRealRoleTest.php: списание и
возврат под боевой ролью crm_app_user. С контекстом клиента деньги двигаются, без
контекста возврат падает громко. Обычные тесты ходят суперюзером и этот класс дыр
увидеть не могут.
- Помощник rejectedCampaign переименован в tgRejectedCampaign: одноимённый помощник
есть у рекламного модуля, помощники Pest глобальные, полный прогон падал фаталом.
Каждая ветка по отдельности этого увидеть не могла.
- Два теста уведомлений считали ВСЮ таблицу целиком вместо строк своего пользователя:
в одиночку зелёные, в полном прогоне красные. Счёт сужен до конкретного пользователя.
- Убраны две проверки отменённой сущности «своё имя отправителя» — сама сущность
дропнута в v9.27 как СМС-фантазия, её адрес отдаёт 405.
Прогоны: телеграм 193/193, реклама 336/336 при 1029 проверках, вместе 532/532,
экраны 1704/1708, сборка фронта чисто, полный Unit+Feature 3923/3960. Шестнадцать
падений полного прогона совпадают построчно с прогоном ветки без телеграма — слияние
не добавило ни одного. Статанализ в свежем каталоге запустить не удалось: он требует
сгенерированного файла-подсказки, которого нет в репозитории, и без него молча падает
на обеих ветках.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Задача 16 закрыта решением владельца. Дороги «робот везёт документ в кабинет Яндекса»
не существует — доказано двумя нарочными отказами, обычной тематикой и лицензируемой:
в окне отказа ноль полей для файла, документы Яндекс принимает только снаружи кабинета.
Приём документа оставлен, но портал больше не молчит: клиент приложил файл — в ленту сразу
ложится отметка «документ у нас, передать его Яндексу автоматически нельзя, при
необходимости отнесём сами и напишем здесь», а владельцу уходит письмо на адрес алертов.
Без письма обещание было бы пустым: файл просто лёг бы на диск. Сам файл письмом
не отправляем — это чужие бумаги. Обычный ответ без файла ни отметки, ни письма не даёт.
Экран «ждёт разбора» в админке: ручка была, экрана не было. Третья карточка на странице
«Реклама» — клиент, кампания, что робот делал человеческими словами, номер объявления
и на чём споткнулся. В подписи прямо сказано, чего там НЕ будет: обычных отказов,
их клиент разбирает сам.
Дальше — разбор собственной работы этого дня. Найдено четыре ошибки, все исправлены.
1. ТЯЖЁЛАЯ. Доклад разведки на бою уронил бы очередь заданий целиком. Робот пишет в ленту
под служебной ролью, а у неё на этой таблице было только чтение. Отказ по правам,
500 роботу, три повтора — и задание навсегда «в работе». Пока хоть одно задание
в работе, выдача отвечает «работы нет» ВСЕМ клиентам. Лечение — запись схемы v9.17:
право на запись плюс нумератор. В плане про это было написано прямым текстом,
я прошёл мимо. Тесты поймать не могли: ходят суперпользователем.
2. Признак «набор создан» я выдумал: взял метку, которая в нашей же разметке описана
как СКРЫТАЯ галочка. Проверка «видно ли её» не сработала бы никогда. Признак с экрана
убран совсем: успех определяет портал слепком креативов, а «окно не закрылось» —
это норма, так и есть живьём.
3. Сломал ленту для повторного отказа. Поменял защиту от дублей на «такой текст уже
когда-либо был» — и клиент, починивший рекламу и получивший тот же отказ, не увидел бы
ничего. Вернул сравнение с последним сообщением, а заглушку «причину выясняем» держит
теперь сам джоб: показываем один раз, пока сказать нечего.
4. Мой собственный тест оказался пустышкой: оставался зелёным при вырезанной защите.
В нём отклонялись ВСЕ объявления, а тогда кампания уходит в «отклонена» и обход её
больше не берёт. Сценарий существует только при частичном отказе — тест переписан
на два объявления и теперь вырезание защиты его роняет.
Портал 391/391, админские экраны 9/9, фронт на затронутых наборах 52/52, робот 74/74,
мест снятия заморозки денег по-прежнему четыре.
На боевой не выкатывалось, рубильник Директа выключен, живьём разведка не гонялась.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Задача 15. Программный интерфейс Яндекса причину отказа не отдаёт — на отклонённое
объявление приходит «Отклонено на модерации.» и всё. Причина висит только на экране
кабинета, и добыть её может лишь тот, у кого есть глаза.
Как теперь работает:
опрос модерации видит отказ и ставит роботу задание разведки по этому объявлению;
робот открывает список объявлений, находит ячейку своего объявления, кликает по статусу,
раскрывает строку причины, читает текст и снимает одно окно; доклад уезжает порталу формой
вместе со снимком; портал кладёт его в ленту от имени Яндекса слово в слово, клиенту
письмо и колокольчик. Робот не понял, что видит — задание сбойное, владельцу письмо,
в ленту клиенту ничего не сочиняем. В админке появилась ручка «ждёт разбора».
Четыре ловушки, пойманные по дороге и проверенные вырезанием:
1. Дедуп разведки нельзя вешать на кампанию. Отказ никуда не девается, а обход бежит
по расписанию: после закрытия первой разведки поставилась бы вторая, и робот ходил бы
в кабинет по кругу. Ключ — номер объявления, журнал схемы v9.16.
2. Рубильник держал не выдачу задания, а построение клиента Директа. Разведке слепок
креативов не нужен, значит при выключенном рубильнике она получила бы задание,
и робот пошёл бы в живой кабинет.
3. Дедуп ленты сравнивал только с последним сообщением Яндекса. После доклада робота
обход снова клал бы «причину выясняем» поверх настоящей причины.
4. Постановка разведки шла без tenant-контекста — на бою она не сработала бы ВООБЩЕ
и молча: поиск дубля давал бы ноль, запись падала бы на политике доступа, всё это
в предупреждение журнала при зелёных тестах. Поймал rls-reviewer. Лечение — своя
транзакция с выставлением клиента, рецепт ChargeCampaignSpendJob. Сторож поставлен
на сам механизм: обычным тестом это не ловится, они ходят суперпользователем.
Заодно: разведке больше не снимается слепок креативов — лишний поход в живой Яндекс
внутри открытой транзакции.
Портал 382/382, робот 75/75, мест снятия заморозки денег по-прежнему четыре.
На боевой не выкатывалось, рубильник Директа выключен.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Обязательно только название фирмы — вывеска. ИНН по желанию: заполнили
проверяем контрольную сумму и ловим дубль, оставили пустым — карточка
заводится без ИНН. Пустая строка приравнена к «не знаю» и уходит как null.
Проверка на дубль по ИНН теперь срабатывает только когда ИНН указан:
раньше вторая карточка без ИНН у того же менеджера ложно ловилась бы как
«эта фирма уже есть в вашей воронке». Схему БД менять не потребовалось —
колонка inn была nullable, уникальный индекс частичный.
Тесты: сервер 58/58, экран 9/9. Спека §16 обновлена.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Обязательно только название фирмы — вывеска. ИНН по желанию: заполнили
проверяем контрольную сумму и ловим дубль, оставили пустым — карточка
заводится без ИНН. Пустая строка приравнена к «не знаю» и уходит как null.
Проверка на дубль по ИНН теперь срабатывает только когда ИНН указан:
раньше вторая карточка без ИНН у того же менеджера ложно ловилась бы как
«эта фирма уже есть в вашей воронке». Схему БД менять не потребовалось —
колонка inn была nullable, уникальный индекс частичный.
Тесты: сервер 58/58, экран 9/9. Спека §16 обновлена.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Разбор клиентского модуля «Реклама в Телеграме по своей базе» на дыры
(4 параллельных код-ревью + личная перепроверка) и план их закрытия.
- findings: 14 находок, сгруппированы по серьёзности; главное — вся денежная
часть латентна под песочницей, но капканы (залипшая бронь, минимум 367 после
freeze, потерянный внешний id, зависшие статусы) сработают при go-live.
- spec: решения владельца (бронь→возврат/списание по факту; «своё имя» и
авторассылка доделываем; начинаем с безопасности), границы, приёмка по областям.
- plan: 5 этапов в порядке 1→2→5→3→4, каждая задача в TDD; этап 3 ждёт живого
отказа МТС (Part B).
Ревизия 27.07 (разбор самих спеки/плана на дыры):
- билинг-модель МТС («от X ₽» = нижняя граница, трата по показам) —
выяснить ДО реализации списания (предусловие этапа 2, задача 2.0);
- внешний id кампании МТС сохранять РАНО (робот плодит реальные черновики уже
на шаге аудитории) — иначе осиротевшие черновики и слепой рефанд;
- уборка брошенных черновиков (сегодня чистили руками) — узаконить (задача 3.1b);
- уборщик зависших консервативен: при известном mts_campaign_id не рефандит вслепую;
- оговорка: тест идемпотентности слабый (dispatchSync последователен).
Только документы (docs/superpowers/*). Кода не трогает.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Модуль-близнец СМС-рассылки, но через робота-в-браузере (у МТС нет API).
Спека: цель, что берём из СМС, ключевое отличие (нет провода → робот, пачки ≥367,
реальные деньги, модерация), клиентский экран, два режима (ручной + авто с лимитом
на объявление), обратная связь по отказу, что требует живой разведки, текст для клиента.
План: 6 сессий по ≤250–300k токенов с логичными остановками под /compact, каждая
оставляет код рабочим; Сессия 5 (отказ) гейтится живой разведкой Сессии 6.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Копия клиентского Яндекс-показы (ветка feat/reklama-yandex-pokazy) для канала ВК:
общий рекламный кошелёк, зеркало guard аудитории с числом ВК (2000), программная
загрузка креатива (проверено живым API content/static.json → операторский шаг для ВК
убираем). Доступ к VK Ads API получен и проверен вживую, ключи на бою, канал под
рубильником services.vk_ads.enabled до go-live. Код не пишем — решение владельца.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Живая проверка боевого кабинета опровергла допущение, на котором стояла Часть C и
часть уже написанного ядра. Конструктор креативов Яндекса закрыт 01.06.2026 —
Яндекс пишет об этом сам плашкой в редакторе объявления, показы его креативов
остановлены с 30.06. Адаптивного креатива из одной картинки не существует: медийная
кампания устроена как объявление на каждый размер блока со своим креативом, что
подтверждает наша живая кампания прогрева из 15 объявлений.
Отдельно проверен read-only запрос creatives.get с боевым токеном: метод отдаёт наши
баннеры, тип у них HTML5_CREATIVE, имя у всех одинаковое «Новый креатив» — опознавать
по имени нельзя, — и приходит PreviewUrl, годный для показа клиенту.
Отсюда дизайн: робот становится грузчиком готовых файлов, а не оформителем креатива.
Номера портал берёт сам через creatives.get слепком «до и после» с сопоставлением по
ширине и высоте. Ядро переходит с одного креатива на кампанию на креатив у каждого
баннера. Решения владельца: файлы готовит клиент, робот сам опрашивает портал, живёт
на боевом сервере, вход заводится через экран и удалённый рабочий стол на localhost.
Дописаны три вещи, не проговорённые в обсуждении: правило частичной модерации —
кампания работает, если принято хотя бы одно объявление, разморозка только когда
отклонены все; минимум один файл и не более одного на размер; раздел честно
неизвестного вместо выдуманных ответов.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Спек по итогам brainstorming с владельцем. Бот-RPA на Playwright автоматизирует
полный цикл создания Telegram-кампании по своей базе телефонов в кабинете МТС
Маркетолог живой сессией браузера, т.к. публичного API для этого нет ни у кого
на рынке РФ. Запуск руками, алярм на почту, два режима черновик/боевой.
Модуль-витрина для клиентов — вне scope, отдельный будущий спек.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Ф0-разведка (находки F0-9…F0-24 + 9 скриншотов), дизайн-спека
и пошаговый план (21 задача, 3 очереди) по UX-правкам рекламного
Яндекс-блока портала. Реализация — в этой ветке от main.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Убран 'class' из образца реестра (сборка через match в makeSmsProvider,
config:cache-safe), цена канала по ключу '*', и честно расписана стоимость
подключения следующего оператора (файл-провайдер + запись + арm + синоним).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Дизайн схемы «МТС-номер → МТС, остальные → СМС-центр» с минимумом работы
при подключении новых операторов: реестр каналов в конфиге, справочник
операторов (OperatorNormalizer), имя отправителя на каждый канал, резерв
выключателем (по умолчанию OFF). Схему БД не трогаем. Утверждено владельцем.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Каждый из 3 рекламных каналов (Яндекс/ВК/Телеграм) получает свои 11 сроков + days;
движок считает решение по каждому каналу отдельно (decideForPlatform, чистая функция);
сроки переезжают на sales_ad_audience_platforms; recalc сводит на фирму для backward-compat
читателей (СМС/карточки); sync-джобы включают номера по срокам своей площадки; заодно
чинится рассинхрон ВК-джоба (читал singleton вместо строки площадки). Состав/СМС/заезд
из поиска — Фаза 2.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Портальная часть (пункты 1,2,3,5,6,7): общий движок таблицы на v-data-table,
ниша+дата колонки и фильтры, Отметить все+счётчик, показ менеджера +
назначение на СМС, пагинация 10/25/50/100, пометки греётся/прогрет + значки
каналов на карточках. Пункт 4 (поиск клиентов) — следующим заходом.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Кусок A (к реализации): фундамент «фирма на площадке», таблица настроек
по площадкам (свой рубильник/пороги/синхронизация), три пункта меню
Яндекс/ВК/Телеграм; поведение прогрева не меняется, 177 номеров → «Яндекс».
Куски B (витрина: значки на карточках, колонки «Греются/Прогреты», история
эпизодов, СМС) и C (раздельные сроки) — дорожная карта. Плюс справочник 11 сроков.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Начальник отдела продаж отмечает фирмы прогрева галочками, пишет текст,
видит цену ДО отправки и журнал после. Отправки СМС в проекте не было
вообще — ни у СМС-центра (только баланс и HLR), ни у МТС (только файл).
Что сделано:
- разъём провайдера SmsProvider: новый оператор подключается одним файлом
- заглушка FakeSmsProvider — модуль работает и проверяется ДО согласования
имени отправителя у операторов (это недели), иначе разработку не закончить
- маршрутизация по оператору: билайновский номер уходит через Билайн за
4,75 ₽, прочие через МТС — без ручного выбора канала
- стоп-лист: кто отписался, тому не шлём никогда, проверка перед списанием
- отбор получателей с шестью причинами пропуска, все ДО траты денег
- списание скопировано с AutopodborChargeService; пока клиента нет
(tenant_id пуст) с баланса не берём — платим оператору напрямую
- оператор номера доезжает из «Поиска клиентов» в прогрев (был известен
и оплачен ДаДате, но терялся при передаче)
Мультиклиентность в костях: колонка tenant_id во всех четырёх таблицах
СМС с первого дня, NULL = «Лидерра сама». Клиент добавляется строкой,
а не переделкой модуля.
Найдено и закрыто при исполнении:
- замок от двойного списания стоял не на том соединении: кампания на
pgsql_supplier, деньги на pgsql, lockForUpdate по кампании отпускался
сразу. На бою два запуска списали бы дважды, обрыв — оставил бы пометку
«оплачено» при неушедших деньгах. Источник правды перенесён в
balance_transactions под замок по тенанту. Доказано тестом: старый код
списывал 700 вместо 850
- приём в портал требовал phones строкой по regex — словарь с оператором
получал 422, в базу не доезжало ничего. Тесты были зелёные, потому что
звали сервис МИМО контроллера. Проверка теперь принимает оба формата,
тест идёт через HTTP
- телефоны директоров в contacts остаются строками (договор
SalesProspectController), словари — только в верхнем phones
Заодно вылечена мигающая поломка 48 тестов доставки лидов: помощник
createRoutingSnapshotFromProject клал снимок на сегодня, а LeadRouter
после 21:00 МСК ищет завтрашний (вечерний переворот заливки) — вечерние
прогоны падали, дневные проходили. Помощник теперь зеркалит активную дату
роутера в любой час. Регрессия SnapshotHelperTimeOfDayTest замораживает
22:00 МСК и пинит инвариант. Боевой LeadRouter не тронут.
Тесты: 84 бэкенд + фронт по экрану + 397 поисковика, весь набор 3226
зелёный, статанализ чист. Все защиты проверены вырезанием.
План: docs/superpowers/plans/2026-07-20-sms-progrev-modul.md
Спека: docs/superpowers/specs/2026-07-20-sms-progrev-modul-design.md
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Постановка владельца 19.07.2026: на экране «Последние списки» нужен фильтр под
выбранную нишу, галочки на списках и групповые действия (удалить / собрать телефоны /
прогреть / отдать менеджеру) — все только по горячим фирмам.
Решения владельца зафиксированы: горячие = 70+, уже собранных и отданных пропускаем
и сообщаем сколько, перед платным действием и удалением спрашиваем с числом,
Телеграм и СМС — заглушки до готовности модулей.
Найдено при проектировании: прогрев берёт только фирмы с собранным мобильным, значит
порядок работы — телефоны → прогрев → менеджер; после прогрева на нашей стороне не
оставалось следа (добавляем пометку площадки); показ 1000 списков требует переноса
счётчиков в колонки, иначе главная разбирает всю базу на каждое открытие.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Признак channels у фирмы, три кнопки и колонка «Где греем» на экране
начальника, заливка в ВК с тремя статусами (нет доступа / ждёт объёма /
работает). Порог автомата у ВК — 2000 номеров, это его же документация.
Зафиксированы находки 19.07: охват списка в ВК меньше сотни при 111
загруженных номерах, и что «111 из 111» у Яндекса — проверка формата,
а не совпадений. Открытый вопрос про перезапись списка в API ВК помечен
явно — уточняется при получении доступа.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Коммит d2c2ec43 от 19.07 оторвался от main (dangling, ни в одной ветке):
чистка ПДн и YandexAudienceClient в основную ветку так и не попали.
Номера заменены на фиктивные 7999000000X, клиент и его тесты внесены заново.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Владелец переформулировал: сначала ГРЕЕМ рекламой, потом отдаём менеджеру.
Прогрев — отдельный этап ДО воронки, карточка рождается при назначении менеджера.
Правила рекламы теперь следуют за стадией карточки, все сроки настраиваются:
прогрев 3 дня, новые 3, взят в работу 14, переговоры до даты созвона
(просрочена → +3 → стоп), недозвон 7, отказ 3, регистрация/тестирование 30,
пополнил баланс и пользователь — стоп.
Проверено на боевых данных: у «Взят в работу» и «Регистрация/Тестирование»
даты созвона нет и не будет — им обязателен свой срок, иначе реклама вечная.
У «Переговоров» дата обязательна в коде, логика владельца закрывает полностью.
HANDOFF содержит промпт для следующей сессии, все технические грабли,
состояние Яндекса (сегмент 58029600, письмо в поддержку отправлено)
и запись об инциденте с ПДн в истории коммитов.
Все телефоны в документах замаскированы.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
docs(sudya): проект сводного судьи диалогов Александры
Собран из трёх существующих семейств судей: голосовые (NISQA/дуэли/glitch),
чатовые (AnswerGuard + слепые судьи-агенты), нормативные (llm-judge/reviewer-agent/
judge-evaluator). Ни одно из них не судило ГЛАВНОЕ — продала ли она; для номера
менеджера по продажам на лендинге это ключевой спектр.
Устройство: приборы (приговор) → коллегия узких судей-ролей (находки) →
судья над судьями (доля промахов). 36 признаков в шести спектрах.
Протокол честности, каждое правило оплачено ошибкой: слепота, нейтральный вопрос,
живой якорь в партии (забраковал якорь → партия недействительна), роли вместо
одной большой рубрики, находка без цитаты источника не считается.
Границы названы явно: звук живых клиентов не пишем (ПДн — отдельная работа),
судья не правит Александру сам, владелец остаётся высшей инстанцией.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@
fix(sales): строгое разделение двух ролей начальника — экраны «мои» больше не показывают отдел
Начальник продаёт сам и руководит отделом. Правило «начальник видит всё»
применялось к ЧЕЛОВЕКУ, а не к экрану, поэтому разделы меню врали:
- «Потенциальные клиенты» показывали все карточки отдела — точную копию
«Воронки отдела» (это владелец и заметил);
- «Мои клиенты» и «Сводка» — всех клиентов отдела;
- «Привязать клиента» — очередь заявок отдела, причём в ЧУЖОМ формате
({pending, history} вместо {data}), форма получала не те данные.
Новое правило: роли разделяются по ЭКРАНУ. Любой запрос по умолчанию отдаёт
только личное — включая начальника. Весь отдел выдаётся только по явному
?scope=department, и просят его только экраны раздела НАЧАЛЬНИК. Менеджеру
параметр ничего не даёт: проверка по роли, не по параметру.
ownedTenantIds теперь ВСЕГДА личные привязки (тип сузился с ?array до array),
добавлен visibleTenantIds для области видимости запроса.
Правом начальника осталось открыть ЛЮБУЮ карточку — кандидата и клиента:
иначе из «Воронки отдела» не открылась бы карточка чужого менеджера.
Ограничены только списки, не доступ к записи.
Следствие: у начальника сейчас 0 своих кандидатов и клиентов, поэтому его
личные экраны станут пустыми — это правильно, а не поломка.
Pest 272/272, Vitest зелёный, vue-tsc чист, Larastan без своих ошибок.
Спека — §23.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@
feat(sales): кабинет начальника — единый период (без 500) + пополнения баланса
Экраны начальника отстали от вчерашних правок кабинета менеджера (§16–§21).
1. Живой баг: «Произвольный» период до выбора дат ронял запрос в 500 на пяти
точках из шести (сводка отдела, доход, результативность, выплаты, тарифы).
Разбор периода вынесен в трейт ResolvesSalesPeriod: 422 вместо падения,
период по умолчанию d30 вместо this — как показывает сам PeriodPicker.
2. Пополнения баланса (topup_rub) добавлены в dashboard/overview (kpi +
строки менеджеров) и managers/performance. На экранах: плашка «Пополнили
баланс» в сводке отдела и колонка «Пополнили ₽» в обеих таблицах
результативности. Из подписей убрано «(мес)» — период больше не месяц.
3. «Воронка отдела» правок не потребовала: она рендерит те же доску и карточку,
что экран менеджера, а карточка сама грузит журнал и сохраняет контакты.
Тесты: SalesPeriodRequestTest проходит по всем шести точкам сразу.
Pest 263/263, Vitest 1420/1420, vue-tsc чист.
Спека — §22.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@
feat(sales): периоды сегодня/вчера/7/30 дней календарём, пополнения за период, скролл доски наверх
Замечания владельца по сводке и доске.
ПЕРИОДЫ:
- Резолвер понимает today/yesterday/d7/d30; «7 дней» = сегодня и 6 предыдущих.
Месячные this/prev/prev2 сервер принимает по-прежнему.
- По умолчанию 30 дней.
- ПОЧИНЕНО: выбор «Произвольный» без дат ронял запрос (500). Теперь понятный 422,
а на фронте период применяется только когда отмечены ОБЕ даты.
- Произвольный выбирается календарём-диапазоном, не руками; порядок дат неважен.
ПОПОЛНЕНИЯ ЗА ПЕРИОД (переиспользован готовый topupsRub):
- Сводка: плашка «Пополнили баланс» рядом с «Σ баланс».
- Мои клиенты: колонка «Пополнил».
Заодно даёт число, которое видимо меняется при смене периода.
ДОСКА: горизонтальная полоса прокрутки поднята НАД колонками (колонки высокие,
системная полоса уезжала за экран); синхронизация в обе стороны, ResizeObserver
на приезжающие карточки.
Спека §21 (включая §21.4 — как по коду заполняется «Требуют внимания»).
Гейты: Pest 257/257 sales+unit, Vitest 1417, vue-tsc чисто, Larastan 0 в своих. TDD.
LEFTHOOK_EXCLUDE: larastan/cspell падают на файлах параллельной сессии.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@
feat(sales): результат разговора и его содержание — одной записью в журнале
Владелец: «объедини в одну запись: договорились… сверху, внизу текст».
Было две записи подряд — в ленте читалось как два события, хотя разговор один.
- БД v8.75: sales_prospect_notes.title VARCHAR(500) NULL — что решили.
- Одна запись kind=note: title = «Договорились на созвон 20.07.2026 17:35»,
body = краткое содержание. Есть результат без содержания — как раньше,
одна запись kind=stage без заголовка. Ручная заметка — без заголовка.
- В ленте заголовок строкой сверху, под ним текст.
- Старые парные записи задним числом не сливаем — историю не переписываем.
Спека §20.2. Гейты: Pest 240/240 sales, Vitest 64/64 воронка, vue-tsc чисто,
Larastan 0 в своих файлах. TDD RED→GREEN.
🪤 Тесты DOM для v-dialog: контент уезжает телепортом в body — искать через
document.body.querySelector, а не wrapper.find.
LEFTHOOK_EXCLUDE: larastan/cspell падают на файлах параллельной сессии.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@
fix(sales): одна кнопка «Сохранить» в карточке — контакты больше не отдельно
Владелец: «исправь сохранения контакта убери, все на кнопку Сохранить заведи».
Две кнопки в одном окне путали: можно было записать результат и уйти, потеряв
только что набранные телефоны.
- Кнопка «Сохранить контакты» и подпись «сохранено» убраны.
- «Сохранить» теперь: сохраняет контакты → если выбран результат, проверяет
и отправляет его → если результат не выбран, просто закрывает окно.
- Контакты не сохранились (нет сети) — результат НЕ отправляем и показываем
ошибку, иначе стадия уехала бы, а телефоны потерялись.
- submit() стал асинхронным, кнопка показывает загрузку.
Спека §20.1. Гейты: Vitest 62/62 воронка (4 новых теста), vue-tsc чисто. TDD.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@
feat(sales): содержание разговора — вместе с результатом; недозвону дата перезвона
Владелец после первого показа карточки: «куда звонить убери; договорились на
созвон — ниже краткое содержание, и оно копится в Историю разговоров, свежие
в начало; недозвон — поставь дату следующего перезвона».
- Блок «Куда звонить» убран: дублировал строку «Телефон общий» из данных фирмы.
- «Краткое содержание разговора» переехало последним полем в блок «Результат
разговора» (было отдельное поле с кнопкой слева — два места для одного
действия). Уходит параметром summary вместе с результатом, ложится в журнал
отдельной записью kind=note. Пустое — не пишем.
- Порядок внутри одного сохранения: сначала автозапись про этап, затем
содержание → у него больший id и в ленте оно оказывается НАД этапом.
- Недозвон получил необязательное поле «Когда перезвонить»: пишется в
next_call_at (видно на плитке) и дописывается в автозапись журнала.
Спека §20. Гейты: Pest 236/236 sales, Vitest 59/59 воронка, vue-tsc чисто,
Larastan 0 в своих файлах. TDD RED→GREEN.
LEFTHOOK_EXCLUDE: larastan/cspell падают на файлах параллельной сессии
tests/Feature/Admin/*Balances*, свои файлы проверены отдельно и чисты.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@
Дмитрий