Рабочий день 06.09: проверки, статусы и iOS-фиксы

Фокус дня

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

• Switchboard — 40%
• AgentChat — 28%
• Блог — 11%
• Sentinel — 7%
• Next — 4%
• LYSAK — 4%
• PULSE — 3%
• Другое — 3%

Switchboard

Switchboard — это страница/контур для запуска и проверки рекламного трафика на русскоязычную аудиторию, сейчас мы смотрим прежде всего на то, как она реально открывается у людей и как ведёт себя Яндекс.Директ. Сегодня важный сдвиг был не в интерфейсе, а в фактической доступности: по логам видно, что реальные пользователи с Android-телефонов уже успешно открывают страницу, приходят свежие 200-ответы с реальных Android User-Agent вроде Xiaomi и Tecno через yclid из кликов Директа. Это означает, что страница открывается людям в России без VPN хотя бы для части мобильных операторов, откуда пришёл этот трафик.

Отдельно разобрали, как правильно перепроверять показ и не путать отсутствие рекламы с поломкой кампании. Для проверки взяли поисковые фразы вроде ии администратор, бот для записи клиентов, автоматизация записи на прием, ресепшн бот и прогоняем их через Яндекс с телефона, не через Google, потому что кампания крутится только в Яндекс.Директ. Смысл здесь простой: сначала подтверждаем, что цепочка «поиск → реклама → открытие страницы» жива на реальных устройствах, и только потом думать о переносе на второй домен или московский сервер.

Рекомендация на завтра: сначала руками проверить открытие https://olehov.com/receptionai с телефона без VPN и только после этого решать, нужен ли вообще перенос на второй домен или отдельная диагностика по провайдеру/DNS/IP. Если у тебя уже есть живой доступ из мобильной сети, дальше полезнее не менять инфраструктуру, а собрать больше фактических подтверждений из Директа. Это уже похоже не на разработку новой фичи, а на этап, где продукту не нужны новые фичи, нужен трафик и пользователи.

AgentChat

AgentChat — это рабочий слой для общения с Claude через телефон и сервер в Amsterdam, где мы одновременно доводим сам клиент, фоновые задачи и уведомления. Сегодня в нём было сразу несколько законченных кусочков: подтвердили жёсткий лимит записи в 10 минут на одну надиктовку, а значит длинная 40-минутная запись сейчас всё ещё режется на клиенте, даже если серверная часть с нарезкой для Timeweb готова выдержать такой объём. Это важная граница: проблема не на сервере, а в клиентском таймере микрофона.

В ветке с уведомлениями и напоминаниями собрали уже почти полный рабочий цикл. Бэкэнд теперь хранит напоминания в data/reminders.json, умеет CRUD через GET/POST /api/reminders, POST /api/reminders/:id/toggle, DELETE /api/reminders/:id, а планировщик работает не отдельным systemd-таймером, а через setInterval внутри agentchat.service, который и так живёт с Restart=always. Он раз в минуту проверяет просроченные напоминания, шлёт push через уже существующую sendPushToAll(), учитывает Courier, бейдж и автоочистку мёртвых подписок, а также пересчитывает daily и weekly повторы. На фронте добавили экран «Напоминания» в шапке рядом с фокусом, форму создания с текстом, деталями, датой, временем и повтором, список активных напоминаний с тумблером и удалением, плюс привязку к текущей открытой сессии. Проверка по стилям тоже была не декоративной: в полях обеспечили нормальный размер шрифта и убрали iOS-zoom-ловушки.

Отдельно подтвердили и статусную механику для фоновых задач. После запуска watch-job.sh в списке сессий теперь появляется статус waiting_background с фиолетовой точкой и подписью «ждёт фоновую задачу», а при завершении задача корректно уходит из pending и completion-маркер доезжает до сервера. Это уже не теория: живой тест показал, что сервер видел маркер, корректно реагировал и логировал ожидаемое поведение для тестового id.

Рекомендация на завтра: если возвращаться к AgentChat, то логичнее всего проверить длинную запись с поднятым лимитом клиента и отдельно закрыть PULSE-доработку со ссылкой «?», которую сегодня не трогали. В целом продукт уже не выглядит как набор идей — основные механики есть, дальше важнее добить надежность и сценарии реального использования.

Blog

Blog — это отдельное PWA-приложение со своим manifest scope и собственной навигацией, где статьи и часть служебных ссылок раньше уводили пользователя в системный браузер iOS. Сегодня разобрали причину поведения без гаданий: ссылки на статьи и «Админ» в разделе «Ещё» ведут на другой домен olehov.com через target="_blank", а iOS для таких ссылок вне scope установленного PWA открывает системный in-app браузер. Это не баг верстки, а штатное поведение платформы.

Из этого разложили понятный план перестройки. Для статей предлагается завести внутренний роут GET /blog-app/post/{slug}, чтобы статья открывалась прямо внутри Blog PWA в его собственной теме и разметке, с нормальной внутренней ссылкой назад на ленту вместо крестика системного браузера. Ссылка в ленте должна стать обычной внутренней, без target="_blank", чтобы телефон не покидал установленное приложение. Внутри статьи при этом останется маленькая вторичная ссылка на olehov.com/blog для тех, кому всё же нужен внешний переход.

Внутри блога мы уже можем держать пользовательский маршрут, а не выталкивать человека наружу — это хорошо ложится на общую идею продукта и упрощает навигацию. Если смотреть на весь стек вместе, то полезно не просто чинить отдельные экраны, а сводить переходы к предсказуемому поведению; для ориентира можно посмотреть и соседние продуктовые ветки, например страницу Sentinel, где тоже важна аккуратная логика входа и переходов.

Рекомендация на завтра: если идти дальше, то сначала внедрять внутренний роут для постов, а уже потом проверять, как iPhone ведёт себя на реальной статье внутри PWA. Это хороший пример того, где продукт уже упирается не в контент, а в UX-навигацию и платформенные ограничения, то есть основная работа сейчас — сделать переходы нативными внутри приложения.

PULSE

PULSE — это наш рабочий продукт для чек-инов, целей и таймеров, где много экранов и форм, а значит любая мелкая CSS-ошибка быстро становится системной. Сегодня нашли именно такую системную брешь: базовое правило input, textarea, select { font: inherit } наследовало font-size: 13px от родительского <label>, из-за чего поля оказывались меньше 16px и iOS Safari начинал зумить при фокусе, а иногда потом не всегда чисто возвращался обратно после Save/blur.

Исправление сделали не точечно, а на уровне всей базы. Для input, textarea, select в styles.css явно поставили font-size: 16px и добавили комментарий, чтобы это не сломали снова. Потом нашли вторую ловушку — более специфичное правило .timer-create-form input { font: inherit }, которое позже в файле переопределяло базу обратно на 13px, и убрали её влияние на поле «Название нового таймера» и тумблеры. После этого через Playwright проверили computed font-size на всех ключевых полях: модалка таймера, создание таймера, цель месяца, цель «принадлежу себе», новые селекты напоминаний — везде теперь 16px.

Ещё обновили скилл prevent-ios-input-zoom, чтобы он учитывал именно наследование от <label>, а не только от body, и добавили обязательную проверку всех совпадений font: inherit/font-size рядом с input/textarea/select. Это полезно не только для этого экрана, а как защита от повторения той же ошибки в других частях продукта.

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

Итог дня

День вышел очень прикладной: мы не столько строили новые большие блоки, сколько проверяли живые сценарии и снимали системные риски. Где-то это была валидация рекламы и доступности на реальных Android-телефонах, где-то — доводка фоновых задач и напоминаний в AgentChat, а где-то — разбор того, почему iPhone уводит людей из PWA и как это исправлять нормально, а не костылём.

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