Рабочий день 21.09: sales, лимиты и фиксы

Фокус дня

Куда ушло внимание за день — по объёму переписки в AgentChat, 322 сообщений всего.

• SalesMachine — 37%
• AgentChat — 16%
• SEO — 9%
• LYSAK — 8%
• Courier — 8%
• Music — 5%
• Почта — 4%
• Mentor — 4%
• ClipForge — 3%
• PULSE — 2%
• SEMVO — 2%
• Нужна помощь на сервере — 1%
• SmartMoney — 1%

SalesMachine

SalesMachine — это наш контур для парсинга, рассылок и подготовки sales-процессов, где мы отдельно держим вкладки, категории, лимиты и оркестрацию. Сегодня по нему было больше всего внимания: мы разбирали, что показывать в интерфейсе, как упростить страницы и как сделать так, чтобы результаты можно было нормально просматривать и сохранять.

Сначала зафиксировали важную вещь: текущая APIшка протухла, и пока новую не сделаем, парсинг нормально работать не будет. Поэтому рассылку как отдельный блок решили не трогать, а сфокусироваться только на парсинге: нужен аудит страницы, определение категорий и более компактная подача информации, чтобы всё помещалось в один экран. Отдельно проговорили, что на вкладке с рассылкой уже не работаем, а весь разбор ведём в парсинговом чате как в ответственном контуре.

Дальше пошёл практический разбор интерфейса. Мы просили убрать лишнюю длину блока, перенести тяжёлый кусок вниз и перестроить страницу так, чтобы ошибки и важные тексты не уезжали вправо, а читались вертикально. Затем вернулись к механике кампаний: агент перезапускал локально процесс на Amsterdam через watch-job.sh, прогонял большой объём запросов и потом отдельно проверял результат v3, включая выборочную проверку категории «Не бизнес» перед заливкой в прод. Это важный момент: мы не просто обсудили план, а довели его до живой проверки внешнего результата.

Параллельно обсуждали новую полезную штуку: сохранённую рассылку. Нам нужна не просто текущая отправка, а объект, который можно сохранить, потом открыть и посмотреть состав письма, количество писем, категории и параметры будущей отправки. По сути, это переход от «настроить и забыть» к «сохранил и потом вернулся посмотреть, что именно уйдёт». Ещё одна развилка дня — делегирование Яндекс-агенту: мы явно закрепили, что он может быть исполнителем маленьких UI-задач, а мы остаёмся оркестратором, который сначала тестирует его на короткой задаче, а потом раздаёт остальные этапы.

Рекомендация на завтра: продолжить разбор SalesMachine как интерфейсной задачи: добить компактный экран парсинга, определить финальные категории и довести до конца сохранённую рассылку как отдельную сущность. Если парсинг уже зависит от новой API, то дальше логично не распыляться на старую логику, а быстро собрать новый рабочий маршрут и проверить его на боевом сценарии.

AgentChat

AgentChat — это наш мобильный рабочий интерфейс для общения с AI-агентами и управления задачами. Через него мы сегодня чинили лимиты, устойчивость сессий и то, как вообще отображается состояние задач на телефоне.

Самый заметный кусок — лимиты моделей и их отображение. Мы разбирали, что у Claude Code, Codex, Kimi и Яндекса есть разные режимы ограничений, а в интерфейсе не хватает места, чтобы всё это нормально показать: в нижнем меню уже не влезают кружочки, а пользователь должен видеть не только цветной индикатор, но и понятный список по провайдерам. В итоге появилась более практичная схема: компактный бейдж вместо нескольких кружочков, сводная модалка со всеми провайдерами, проценты лимита в списке выбора модели и отображение времён в московской зоне, а не в UTC-стиле без контекста.

Параллельно мы поправили саму логику индикаторов. Был найден баг, из-за которого бейджи показывали только худшее из двух окон лимита, а второе значение терялось. Это исправили: теперь короткое окно и недельный остаток видны отдельно, а пороги цвета приведены к более раннему предупреждению. Отдельно проверили, что задачу можно выполнять живьём под systemd-таймером и что она стабильно проходит по всем трём провайдерам без падений. Это уже не просто визуальная косметика, а реальная дисциплина вокруг лимитов: пользователь должен понимать, когда ресурс заканчивается, и не гадать по одним кружочкам.

Ещё одна важная ветка — делегирование Яндекс-агенту. Мы разобрали, почему раньше бейджик не появлялся: фоновые задачи запускались в обход обязательного watch-job.sh, и сервер не понимал, что сессию нужно ждать. После этого мы отдельно проверили одновременный запуск Яндекс-агента из нескольких сессий и зафиксировали ограничение общей SQLite-базы: без изоляции второй параллельный запуск падает. Это полезный практический вывод для дальнейшей оркестрации, и мы сохранили его в памяти и в отдельной записи.

Рекомендация на завтра: не добавлять ещё один слой сложности к лимитам, а сначала закрепить уже сделанную схему на телефоне и в браузере: бейдж, модалка, московское время, уведомление о разблокировке. После этого уже можно спокойно думать о следующей итерации оркестрации Яндекс-агента.

SEO

SEO — это наш контур, где мы смотрим на структуру публичных страниц, индексирование и то, как продукты OleHov видны поисковикам. Сегодня работа пошла не в абстрактный аудит, а в конкретный технический фундамент: поиск реальных сервисов, sitemap, robots и проверка внешних ответов.

Сначала мы разделили разные сущности, чтобы не смешивать продукты, SEO-страницы и отдельный кабинет. Потом пошли по факту: нашли реальные сервисы за PULSE, SEMVO, NEXT, ClipForge и ContentFactory, исправили robots/sitemap в их собственных кодовых базах и добавили пропущенные страницы в sitemap olehov.com. То есть это был не просто «SEO-план», а вполне прикладная работа по наведению порядка в том, что поисковики вообще должны видеть.

Отдельная важная развилка — понимание, что у нас два поисковика: Google и Яндекс, и для России это значит, что техническое SEO должно учитывать оба. На этом фоне обсуждали и SEO-приложение как отдельный кабинет: уже есть технический SEO-экран, но удобный продуктовый интерфейс ещё не готов, и его нужно строить как отдельную витрину, а не как случайный хвост внутри другого дашборда. Параллельно выясняли, что общий lock на /opt/olehov мешает параллельным правкам, поэтому часть работы пришлось ставить в ожидание до безопасного окна.

Был и ещё один практический кусок: для PULSE агент получил ограниченную задачу по карте интентов, создал только отчёт и реально израсходовал квоту, то есть мы не тянули вслепую, а проверяли пилотный SEO-процесс на конкретном продукте. Это хороший знак: у нас уже есть техническая основа, и теперь нужно просто аккуратно наращивать покрытие, не ломая рабочие проекты.

Рекомендация на завтра: добить окно по /opt/olehov, чтобы вынести продуктовый разрез в SEO-PWA и проверить его внешним readback. Дальше уже можно двигаться волнами по продуктам, а не распыляться на случайные страницы.

LYSAK

LYSAK — это сайт художника и связанные с ним страницы, где мы работаем с контентом, изображениями и текстами без дублей. Сегодня по нему была в основном чистка и обновление блока с топ-картинками.

Сначала убрали дубль текста на странице биографии: повторяющаяся цитата под заголовком «О художнике и пути» была удалена, и после проверки на живом сайте текст остался в единственном экземпляре. Потом отдельно прогнали аудит на дубли текста и id и получили чистый результат: после вчерашнего фикса дубли больше не найдены.

Параллельно шла большая работа по разделу «Топ». Мы обновили карточки, заменили изображение в «Топ 1 — Улитка» на присланный оригинал, а затем довели раздел до полностью рабочего состояния на боевом сайте. В результате на месте оказались несколько карточек с фото, подписями и кнопками «Поделиться», сайт отвечал HTTP 200, а позже проверили уже все 8 карточек «Топ», включая «Вороны» и «Девочка и парус» с точными подписями с оборотов. В процессе были и сбои с возобновлением сессии, и ошибки thread/resume, но конечный внешний результат подтвердили.

Рекомендация на завтра: если ещё остались незагруженные изображения из последней пачки, спокойно добить их в том же стиле и потом уже ничего не менять без необходимости. По LYSAK сейчас важнее не придумывать новое, а сохранить уже достигнутую чистоту и консистентность.

Courier

Courier — это центр управления уведомлениями и журналом их доставки. Сегодня мы в нём в основном выключали лишние пуши и проверяли, что отключение происходит по реальному отправителю, а не только в интерфейсе.

Были отключены несколько конкретных уведомлений: «Яндекс.Директ / Direct Daily», затем «Dashboard Health» и отдельное уведомление про готовый Reels. В каждом случае мы сверяли журнал Courier, находили реальный источник, отключали штатный тумблер и проверяли, что отправка действительно прекращена. Это важный момент: мы не просто гасим внешний шум, а подтверждаем, что боевой путь доставки больше не срабатывает.

Отдельно выяснили полезную вещь: иногда тумблер в интерфейсе уже выключен, но уведомление всё равно приходит. Значит, нужно смотреть не только на визуальный статус, но и на обходящий его отправитель. Для Dashboard Health мы отключили Telegram-оповещения о нагрузке сервера, недоступности сайта и остановке runner-процессов, при этом сам мониторинг и сбор метрик остались включёнными. Это как раз тот случай, когда продукт становится тише, но не слепнет.

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

Рекомендация на завтра: не добавлять новые уведомления, пока не будет окончательно стабилизирован принцип «один источник — один тумблер — один боевой readback». Иначе снова получится много настроек, но мало понимания, что именно живёт и что именно выключено.

Disk

Disk — это наш файловый контур, по сути мобильное приложение/веб-интерфейс для загрузки и управления файлами на серверах. Сегодня он прошёл от идеи до проверенного end-to-end результата.

Сначала мы описали саму концепцию: единое место, где с телефона можно закидывать файлы на Amsterdam или Moscow, а потом управлять ими из одного интерфейса. Потом был план: backend на files.js, PWA-оболочка, auth, деплой и возможность открывать всё через мобильный сценарий. Мы даже разделили это на этапы и отдали первый кусок Яндекс-агенту.

Финальный результат получился уже не теоретическим. Backend по files.js был проверен реальными запросами: list, upload, download, mkdir, delete, а также защита от path traversal и корректные коды ответов на граничных сценариях. После этого было сказано прямо: «Диск OleHov готов и проверен end-to-end». Это значит, что уже есть не просто идея, а рабочая база для файлового приложения, которым можно пользоваться через обычный OleHov-аккаунт.

Рекомендация на завтра: если хочется расширять Disk, лучше идти не в новые сложности, а в удобство на телефоне: быстрый вход, понятные папки и предсказуемые операции с файлами. Само ядро уже достаточно сильное, чтобы на нём строить интерфейс без страха сломать основу.

Коротко по остальному

PULSE: обсуждали управление публикациями в Telegram-канал из админки, тумблер включения/выключения и время публикации; это логично ложится в существующий продукт, где уже есть чек-ины, привычки и подписка.

Рекомендация на завтра: добить MVP именно как управляемую настройку, а не как отдельную разрозненную функцию.

SEMVO: проверяли причину сбоя и отдельно разбирали платёж на 300 ₽, который, похоже, был связан с чатом «Катя»; это была не абстрактная диагностика, а сверка факта оплаты и источника уведомления.

Рекомендация на завтра: продолжить разбор платежа и уведомлений только после точного подтверждения владельца записи.

Music: продолжили идею REMIX — инструмента, который собирает короткие видео в ролики разной длины, и начали с серверной части MVP, плюс прикинули, какой сервис подойдёт для бесплатной публикации trial reels.

Рекомендация на завтра: не распыляться на много платформ, а сначала проверить один устойчивый сценарий публикации.

Почта: открывали письмо Publer, пытались пройти verification и потом временно остановили задачу; в итоге браузерную сессию закрыли, пароль не трогали, форму не отправляли.

Рекомендация на завтра: если вернёмся к Publer, сначала проверить сам путь авторизации, а не идти сразу в заполнение формы.

Mentor: проверяли возможность удалённой публикации и получили прямую ссылку на профиль olehovmentor, а также отдельно разбирали подтверждения входа через Instagram/Meta.

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

Итог дня

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

Параллельно стало видно, что мы постепенно собираем общую операционную систему вокруг продуктов: AgentChat как рабочий пульт, Courier как центр уведомлений, SEO как техническая видимость, Disk как файловый доступ, SalesMachine как sales-ядро. День был тяжёлый, но очень полезный: много мелких фиксов сложились в несколько уже вполне зрелых контуров.

В этой картине отдельно полезно смотреть на SalesMachine: там уже видно, как мы уходим от разрозненных экранов к более управляемой сущности, которую можно сохранить, проверить и потом снова открыть без потери контекста.