Экосистема

ТЗ 289 «Контроль рассылки». 19 октября 2026 года с продакшена my.ipd.by ушла массовая рассылка, о которой администратор узнал постфактум: письма формируются по расписанию и уходят сами (буфер PreparedEmail и кампании Campaign), а отдельного предупреждения о запуске не было. Теперь платформа заранее сообщает администратору в Telegram: за 24 часа, 4 часа, 1 час и 15 минут до отправки ближайших писем приходит одно сводное сообщение со числом писем и списком получателей и тем. Каждое пороговое окно отправляется один раз (дедупликация в таблице mailing_alerts), повторные запуски не дублируют предупреждения. Версия v0.98.0.

ТЗ 284 «Категории проектов». Раздел проектов жил на одном адресе /admin/projects с параметром ?scope=all|clients|mine — состояние страницы нельзя было запомнить, отправить в ссылке или открыть в новой вкладке. Теперь у каждой категории свой постоянный адрес: /admin/projects (вход — клиентские активные, как раньше), /admin/projects/clients|all|mine и /admin/projects/clients|all|mine/active|completed|all (например /admin/projects/clients/completed — завершённые клиентские). Сверху два ряда вкладок: разделы и статусы, каждый со своим счётчиком; счётчики считаются в рамках выбранного раздела до применения статуса, поэтому «Клиентские · завершённые · 7» честно показывает, сколько станет после клика. Старые ссылки ?scope=X ведут на постоянный адрес того же раздела, поиск/сортировка/пагинация остаются параметрами и не меняют адрес. Версия v0.96.2.

ТЗ 283 «Задачи клиентов». Страница /admin/tasks-platform по умолчанию открывалась списком «моих» направлений (config('sync.my_directions')) — админ видел работу разработчика, а не то, что ждёт клиентов. Теперь по умолчанию показываются клиентские задачи: всё, кроме зоны ответственности — направлений «Производство», «Поддержка, сервис» и задач, где исполнитель (meta.assignee) — он сам. Сверху появился переключатель-чипсы «Клиентские (дефолт) / Все / Мои» (?who=clients|all|mine) с живыми счётчиками: «мои» = всё, что связано со мной — мои направления, мои проекты (клиент проекта — я сам, clients.personal_client_id) и задачи, где исполнитель — «Администратор» либо «Алексей Гапеев», «клиентские» — всё остальное, «все» — весь список. Счётчики чипсов направлений и статусов считаются в рамках выбранного режима (в «Клиентских» направления зоны ответственности показывают 0 — это честно, клик ведёт в пустой список). Старые ссылки ?direction=my|all|<id> сохраняют прежний смысл: направление по-прежнему открывает полный список задач направления, а ?direction=my работает как «Мои». Версия v0.96.1.

ТЗ 282 «Обращение к получателю». Поле «Обращение к получателю» было видно только в редактировании, о пустоте админ узнавал по письмам: когда поле пустое, письмо начинается строкой «Здравствуйте, <первое слово ФИО>!» (для «Авраменко Виолетта Владимировна» — «Здравствуйте, Авраменко!», то есть с фамилией). Теперь на карточке пользователя в списке и на его странице сразу видно, как система обратится к человеку: заполненное обращение — зелёный бейдж, пустое — красное предупреждение с тем, что уйдёт в письмо по умолчанию. В колокольчик администратору приходит уведомление «Не заполнено обращение» с числом таких клиентов (считаются рабочие клиенты: статус «В работе», активный вход, роль «Клиент») и ссылкой на список. Изменения полей пользователя логируются понятными подписями («Обращение к получателю: «…» → «…»») с автором действия. Версия v0.96.0.

Дедлайн проекта был завязан только на активную подписку: у проектов без подписки карточка «Дедлайн» показывала «—», хотя срок завершения у проекта есть. У проекта появилось собственное поле deadline (планируемая дата завершения) с отдельным полем в редактировании; на странице проекта показывается оно, а если пусто — дедлайн из подписки с пометкой «по договору». Заодно задачи на странице проекта превращены из списка с процентами в карточки: поставлена дата и время, крайний срок, дата выполнения, описание, прогресс (с платформы задач, иначе доля выполненных шагов) и шаги с отметками «сделано / не сделано». Выполненная задача никогда не считается просроченной и всегда показывается на 100% со всеми шагами отмеченными; шаги идут вертикальным списком с номерами. Версия v0.95.0.

ТЗ 280 «Ссылки в тексте». Ссылка выглядела как обычный текст, и человек не знал, что на неё можно нажать. Причина оказалась не в вёрстке, а в токенах: общее правило a { color: var(--link); text-decoration: underline } в resources/css/app.css было и раньше, но локальные правила экранов его перебивали — красили ссылки в --accent (в тёмной теме #e2e8f0, в светлой #0f172a, то есть в цвет текста) и убирали подчёркивание. Исправлено 26 файлов blade и сам app.css. Кнопки, вкладки, карточки, кебаб, пагинация, сортировка, хлебные крошки и навигация сайта остались без подчёркивания — это элементы управления, у них свой вид. Версия v0.94.2.

ТЗ 279 «Буфер писем, управление». В буфере было видно, что письмо зависло, но нельзя было ничего с ним сделать: ни удалить, ни отредактировать — приходилось искать письмо в общем списке и терять его там. Теперь у каждого письма в буфере есть галочка и меню действий, а над списком — панель массовых действий: отметили пять ненужных писем и удалили их одним действием, не покидая страницу. Попутно исправлена ошибка, из-за которой после успешного массового удаления показывалось ложное сообщение об ошибке, и счётчики групп буфера перестали расходиться с тем, что на экране. Версия v0.94.1.

ТЗ 278 «Буфер писем». Ссылка «Буфер писем» в меню вела в общий список всех писем, где нужное письмо найти невозможно, а плитка «Сегодня/завтра» считала ближайшие 24 часа от текущей минуты и показывала 0, хотя письма на сегодня были. По умолчанию теперь открывается буфер: просроченные письма отдельным блоком, дальше сегодня, завтра и каждый следующий день до конца недели. Периоды считаются по календарным дням. Версия v0.94.0.

ФИО в списке пользователей переносилось по две буквы. Причина найдена замером, а не на глаз: в таблице из 11 колонок колонка «Имя» сжималась до 63px при ширине окна 1440px — «Тариф» с длинным названием занимал 287px, а «Роль», «Статус» и «Вход» по 90–144px каждая; сверху `overflow-wrap:anywhere` разрешал рвать слово в любом месте. Список переведён с таблицы на карточки: у каждого поля своя ширина, имя занимает свободное место целой строкой и переносится только по словам. Замер после изменения: ширина имени 419px при 1366px, одна строка на всех ширинах до 360px. Сортировка вынесена в отдельную строку над списком, все поля и меню действий сохранены. Версия v0.93.3.

ТЗ 277 «У Дмитрия ноль проектов и горизонтальная прокрутка». В списке пользователей счётчик проектов считал только участие человека в проекте (client_project). Владелец проекта в эту связь не попадает намеренно, поэтому у клиента с собственным проектом стоял ноль. Теперь счётчик берёт объединение «владелец + участник» без двойного учёта, а роль в счётчике подписана явно. Тот же подсчёт перенесён в фильтр «С проектами» и в блок статистики — раньше список и счётчик показывали разные числа. Вторая часть задачи — адаптивность: таблица пользователей из 11 колонок скрывает второстепенные колонки по ширине экрана, широкие таблицы прокручиваются внутри себя вместо растягивания всей страницы, шапка переносится на узких экранах. Версия v0.93.2.

Восстановлен функционал управления письмами на неделю/месяц: добавлены кнопки «Сформировать на неделю/месяц», «Пересобрать на неделю/месяц» (с отменой будущих в выбранном периоде и повторной генерацией), роуты и методы контроллера. После генерации автоматически очищаются просроченные queued (scheduled_at <= now). Статистика «На неделю/месяц» в админке стала корректной.

Исправлена проблема, когда письма в статусе «В очереди» с запланированной датой в прошлом оставались в очереди и могли быть отправлены позже. Теперь команда email:send-prepared автоматически отменяет сильно просроченные queued (>48ч) и берёт в отправку только актуальные по расписанию.

ТЗ 273 «Люди загрузились, а проектов у них нет». Загрузка людей и загрузка проектов были разными кнопками в двух мастерах, и порядок зависел от того, какую нажали: люди успевали появиться раньше проектов — и проект оставался без владельца, а у клиента не появлялось ни одного проекта. Причина в сопоставлении: у человека без почты на площадке person_external_id пустой, а почта в карточке проекта и в списке людей расходится, поэтому владелец не находился вообще. Теперь одна кнопка «Синхронизировать всё» делает всё в правильном порядке (направления → люди → проекты → связи «человек → проект» → задачи) и одной транзакцией, а владелец проекта ищется через общий список людей по person_id — это работает и без почты. Версия v0.92.0.

ТЗ 272 «Одна кнопка и правдивые письма». Люди без email молча пропускались, а смена статуса задачи нигде не сохранялась — платформа отдаёт только текущий статус, поэтому письмо об изменении просто не могло появиться. Теперь: клиент без email создаётся с пустой почтой (появится в проектах и списках, писем не получит); каждый переход статуса «было → стало» пишется при синхронизации в новую таблицу task_status_changes и выводится в отчётных письмах плейсхолдером {{status_changes_list}}; сопоставление человека с клиентом вынесено в один сервис PersonMatcher для превью и импорта сразу. Попутно исправлена ошибка сопоставления по кириллице: сравнение шло через SQL LOWER(), который в SQLite не понижает регистр кириллицы, из-за чего людей без почты создавали заново при каждом импорте. Версия v0.91.0.

ТЗ 271 «Задачи велись в двух местах». Задачи приходят с платформы task.ipd, но в MY IPD у синхро-задач были свои формы правки: маршруты create/store/edit/update/destroy и отдельный AdminStepController для шагов. Правка жила до следующей синхронизации и затиралась, удалённая задача возвращалась из выгрузки снова. Для синхро-задач маршруты правки удалены, карточка задачи только читается, кнопка «+ Задача» на странице проекта убрана; удаление осталось только в сверке мусора. Причина заваленности базы: 1112 синхро-задач, из них 327 на платформе нет вообще (тестовые D-04…D-111 и прочие), а 196 задач были ошибочно помечены «нет на платформе» — синхронизация сверялась по ответам на отдельные запросы вместо полного списка задач платформы. Предпросмотр и SyncManager теперь считают известные идентификаторы по объединению всех источников. Добавлена команда tasks:reconcile-platform с режимами --dry-run, --restore, --purge. На TEST удалено 327 задач и 20 шагов, 196 задач восстановлено. Версия v0.90.1.

ТЗ 270 «Месячные письма приходят пустыми». Найдено две причины. Первая: экспорт платформы задач /api/export/full вообще не отдаёт дату закрытия задачи — синхронизация её никогда не заполняла, поэтому 667 закрытых задач оставались без даты, а отчётный период — это диапазон дат, и задача без даты не попадала ни в один месяц. Добавлена команда tasks:import-completion-dates, которая берёт completed_date из БД платформы напрямую (подключение task_platform) и сверяет задачи по внешнему идентификатору; на TEST проставлено 460 настоящих дат (162 за июль, 95 за август, 123 за сентябрь), снесено 60 выдуманных дат, поправлено 3. Вторая: пустое письмо всё равно уходило клиенту. Добавлен гейт наполнения — письмо, в котором нет ни задач, закрытых внутри отчётного месяца, ни задач в работе, не отправляется, а остаётся в черновиках с причиной; тело письма пересобирается по свежим данным проекта прямо перед постановкой в очередь, потому что буфер готовится за месяцы вперёд. Версия v0.90.0.

ТЗ 269 «Месячные письма называют не тот месяц». Генератор будущих писем email:generate-upcoming готовил месячный дайджест с датой отправки как отчётной: письмо, намеченное на 1 октября, называлось «Ваш проект — итоги за Октябрь 2026» ещё до начала октября, и список выполненных задач отбирался за неверный месяц. Сборка месячного письма вынесена в единый сервис MonthlyDigestService, где отчётный период всегда равен месяцу отправки минус один. Месячный отчёт — один на клиента и собирается по его текущему проекту (вместо письма на каждый активный проект), а требование активной подписки снято: получателем является любой клиент со статусом «В работе». Добавлена команда email:rebuild-monthly для пересборки буфера. На тестовом стенде пересобраны месячные письма с октября 2026 по март 2027 — 60 писем для 10 клиентов «в работе», каждое с подписью предыдущего месяца. Версия v0.89.0.

ТЗ 268 «На production уходят письма не тем клиентам». Найдена и устранена первопричина: команда email:send-prepared отправляла всё, что лежит в буфере со статусом queued, не проверяя текущий статус клиента — адрес в письме был снимком на момент подготовки, а не текущими данными клиента. Теперь перед отправкой проверяется, что клиент активен, имеет статус «В работе», не отписался от email-рассылки и что адрес письма всё ещё входит в список его адресов; иначе письмо снимается в статус «Отменено» с причиной в admin_notes и не отправляется. Генераторы месячных писем mail:send-monthly и email:generate-upcoming тоже переведены на Client::emailActive, поэтому клиентам в корзине и на проверке письма больше не создаются вовсе.

ТЗ «Отчёты перестали повторять старые задачи». Список выполненных в отчётах больше не строится как «все completed, limit(5)»: добавлена дата закрытия задачи tasks.completed_at, которая проставляется в момент реального перехода в статус «выполнена». В письмо попадает только то, что закрыто внутри выбранного периода — недели, месяца, календарного сезона или года. Каждое отсеяние объясняется причиной, администратор видит состав отчёта в предпросмотре и может снять задачу вручную, а повторная отправка за тот же период больше не дублирует уже отправленные задачи. Версия v0.87.0.

ТЗ «Дизайн стилей при просмотре письма». Просмотр письма в /admin/emails/{id} переведён на изолированный рендер: содержимое письма отдаётся отдельным HTML-документом (iframe srcdoc на странице и полноценный standalone-документ по маршруту /admin/emails/{id}/preview), поэтому стили письма больше не протекают в админку (чёрный текст на чёмном фоне, белые кнопки с белым текстом), а стили админки не ломают письмо. Добавлена кнопка «Открыть письмо» — открывает письмо отдельным документом в новой вкладке. Версия v0.86.0.

ТЗ 263 «Дозированная отправка». Письма на один и тот же почтовый ящик (получатель ИЛИ BCC-копия администратору) теперь уходят с паузой по умолчанию 5 секунд (настраивается MAIL_SAME_RECIPIENT_INTERVAL), чтобы адресат не получил залп из десятков писем разом — типичный триггер спам-фильтров. Разным получателям письма отправляются сразу. Очередное письмо дожидается паузы только если в тот же ящик реально ушло предыдущее; пропущенные дубли и dry-run паузу не сбивают. Версия v0.85.3.

ТЗ 262 «Обновления проекта как 5468». Все queued/draft письма «Обновление проекта» (62 письма, № 5552–5613) пересобраны по архитектуре эталона 5468: изменения сгруппированы по задачам, каждая задача показана полной карточкой (чип статуса, прогресс-бар, даты «Задача поставлена / Планируем завершить», этапы с галочками, описание), события — бейджами с датами. Обращение к духовным лицам («Отец Николай», «Отец Досифей») больше не усекается до «Отец» — greeting в письмах «Здравствуйте, отец Николай!». Месячные письма отца Николая (6 писем, № 5409–5414 на октябрь 2026 – март 2027) пересобраны с новым обращением. Версия v0.85.2.

ТЗ 261 «Месячные письма как 5468». Queued месячные дайджесты (24 письма на 01.10.2026–01.03.2027) пересобраны по архитектуре эталона 5468: вместо плоских зелёных блоков задачи рендерятся карточками со чипом статуса, прогресс-баром, датами «Задача поставлена / Планируем завершить» и описанием. Обращение в письме теперь по имени («Здравствуйте, Егор!»), а не по ФИО. Синхронизирован БД-шаблон monthly-digest с богатым телом; отправленные сентябрьские письма не тронуты. Удалены 6 дублей-копий старого шаблона и 3 устаревших черновика. Письма Марины Лакатун (клиент 24) перенаправлены с удалённого проекта «Ришелье стиль» (355) на актуальный проект 371; месячные письма клиентов Татьяны (25) и Любови (26), исключённых из рассылки, удалены. Версия v0.85.1.

ТЗ 260 «Несколько email». У человека на платформе задач может быть несколько email — один основной. Кнопка «Синхронизировать с платформы задач» привела email клиента и список всех его адресов к данным платформы: основной email (по нему уходят письма и идёт вход в кабинет) обновляется у той же записи, а полный список хранится в новой колонке clients.emails и виден в карточке пользователя (основной — с бейджем «основной»). История писем при смене ящика не теряется: она хранится по client_id и фактическому адресу в prepared_emails.to_email / mail_logs, поэтому старые отправленные письма остаются у старого ящика, а новые уходят на новый. Письма Егора Савинского (16 писем в очереди и черновиках) переадресованы на новый основной ящик esav2@yandex.ru. Версия v0.85.0.

ТЗ 259 «Письма как 5468». В обновлении 0.77.2 (ТЗ 247) письма-уведомления о задачах посерели: зелёные плашки «выполнено», цвета статусов и синий призыв заменили на нейтральный серый, и письмо слилось в один безликий блок. Вернули цветную архитектуру эталона 5468 и распространили её на письма, которые готовились к отправке. Статусы задач, галочка «выполнено», блок «Обслуживание и поддержка», регламент и кнопка личного кабинета снова цветные. Вступительный текст письма стал зависеть от проекта: у проекта «Медтехника Гродно» — прежний текст, у остальных — общий. Писем, лежащих в очереди отправки, это касается напрямую: их тела пересобраны по новой архитектуре. Автотест проверяет, что в шаблонах писем статусы не серые, а цветные (эталон 15/15).

ТЗ 258 «Контраст кнопок». Кнопки «Новое письмо», «Найти», «Сохранить», «У нас / У клиента» и им подобные на светлой теме выглядели как серые прямоугольники, а надпись на них не читалась: белая надпись лежала на светлой заливке. Причина была одна и системная — заливка кнопки бралась из токена темы, который в тёмной теме тёмный, а в светлой — светлый, и надпись на нём всегда оставалась белой. Вместо «цвет под текущую тему» появились отдельные токены заливки: --btn-solid, --btn-solid-hover и --on-btn-solid. Они одинаковы в тёмной и светлой темах, поэтому надпись читается в обеих (контраст от 6:1). Попутно та же правка убрала такие же белые надписи на зелёных и красных ховер-состояниях Telegram-виджета и формы «Оставить заявку», на аватарах, на бейдже непрочитанных уведомлений, на тостах, на кнопке закрытия в просмотре версий и на кнопке в письме-напоминании. Кнопки действий в разметке переведены с inline-стилей на классы btn btn-primary / btn-sm. Эталон тестов 321 passed, эталон сборки vite build.

ТЗ 257 «Пользователи, ссылки». Слева в меню было одно слово «Пользователи», и по нему открывался общий список всех людей: сначала нужно было догадаться, где сейчас тот, с кем мы работаем, а потом ещё переключиться на нужную вкладку. Теперь у каждого состояния свой постоянный адрес: /admin/users — люди, с кем работаем сейчас, /admin/users/review — на проверке, /admin/users/trash — в корзине, /admin/users/deleted — удалённые, /admin/users/all — все вместе (нужен редко, для сплошной проверки, поэтому стоит последним и тихим). Вкладки «?bucket=…» заменены адресами, поэтому внутрь любого раздела можно добавлять под-страницы, а ссылку можно отправить другому человеку — она всегда откроет то же самое. Старые ссылки с вопросиком не сломаны: такой адрес один раз переводит на постоянный и дальше живёт по нему. Версия v0.83.0.

ТЗ 256 «Корзина пользователей». У человека был один переключатель «Активен/Неактивен»: выключенный пользователь просто исчезал из рассылок, но оставался в общем списке без следа, почему его больше нет, и без возможности вернуть его в работу. Теперь у пользователя отдельный статус-корзина из четырёх состояний: «В работе» → «На проверке» → «В корзине» → «Удалённые», и каждое состояние возвращается в работу одним действием. Статус не пересекается с переключателем «Вход» (is_active): статус решает, отправляем ли мы человеку письма и отчёты, а «Вход» — пускаем ли мы его в личный кабинет. На странице пользователей появились вкладки с постоянными счётчиками («Все · N / В работе · N / На проверке · N / В корзине · N / Удалённые · N»), отдельная колонка «Статус» с бейджем и новые пункты кебаб-меню: «На проверку», «В корзину», «Вернуть в работу», «Восстановить», «Удалить навсегда». «Удалить» стало мягким: запись уходит в «Удалённые» вместе со своими проектами и письмами, её можно восстановить; «Удалить навсегда» доступно только оттуда и вычищает связанные данные. Письма и отчёты не отправляются всем, кто вне «В работе»: гейт стоит в scopeEmailActive, в подборке получателей кампаний, массовых уведомлений, недельных отчётов и статусов задач, а вход закрыт в логине, смене аккаунта, автовходе и восстановлении пароля. Версия v0.82.0, эталон тестов 312 passed.

ТЗ 255 «Вкладки». Форма редактирования пользователя собирала все поля в одну простыню: постоянные данные (имя, обращение, email, компания, телефон, Telegram, подтверждения контактов) и то, что правится постоянно (роль, проекты, доступ к платформам), были на одном экране — человек прокручивал десятки полей, чтобы добраться до нужного. Форма разбита на вкладки одного экрана по образцу платформы задач (task.ipd project-edit / person-edit) и встроенной страницы проекта: «Основная информация», «Настройки», «Проекты», «Платформы». Один экран, одна форма и одна кнопка «Сохранить»: вкладки только группируют поля, маршрут обновления не изменился, внизу панель «Сохранить/Отмена/Безопасность» с подсказкой «Все вкладки — одна форма: данные сохраняются одной кнопкой». Кебаб-меню платформы научилось открываться от края окна: кнопка внизу (низ карточки пользователя) раскрывает меню вверх, а не за край экрана, у левого края — вправо, у правого — влево; авто-направление — `positionKebabMenu()` в `toggleKebab()` (`layouts/app.blade.php`). Правило зафиксировано в методологии: «03 Стиль интерфейса» раздел 7.1 (длинные формы — вкладки) и 5.1 (открытие кебаб-меню), «02 Правила разработки» — блоки проверки. Эталон тестов 305 passed.

ТЗ 254 «Локальные проекты». Найдена причина, по которой в списке проектов появлялись пустые строки с бейджем «Локальный»: их создавал сам DatabaseSeeder — при каждом запуске `php artisan db:seed`, то есть при каждой смене версии платформы, он вставлял пять проектов-шаблонов каждому клиенту без проверок. Один запуск 25.09.2026 в 20:40:16 дал 93 проекта с нулём задач, нулём участников и нулём писем, а заодно привязал четыре демо-токена к пустым проектам. Демо-данные вынесены в отдельный DemoSeeder, который запускается только на пустой базе и больше не вызывается при смене версии; учётная запись администратора больше не переписывается (пароль не сбрасывается, дата создания не затирается). Из базы удалены 93 мусорных проекта и 4 демо-клиента вместе с их токенами.

ТЗ 251 «Куча пользователей в проекте». Найдена причина, по которой в проекты попадали люди, которых никто не добавлял: синхронизация с платформой задач молча прикрепляла каждого участника из project_ids и при этом ещё раз прикрепляла владельца проекта как обычного участника. Теперь привязка владельца пропускается, а каждая новая связь получает дату, источник и автора. Управление составом вынесено на отдельную страницу /admin/projects/{id}/members: видно, кто привязан, когда, откуда (вручную в my.ipd или синхронизацией с платформой задач), кем добавлен и было ли это массовым заходом; там же — история изменений состава. На странице проекта широкая таблица пользователей заменена компактной карточкой со сводкой и переходом на новую страницу, добавление участника получило свой адрес /members/create, а сломанная вёрстка шапки страницы (незакрытый div, из-за которого вся страница попадала в flex-блок) исправлена.

ТЗ 250 «Проекты клиента». Список проектов человека вынесен с карточки пользователя на отдельную страницу /admin/users/{id}/projects и отвечает на вопрос «почему их восемь, если проект один». Для каждого проекта видно, откуда он: пришёл с платформы задач (с её ID и датой синхронизации) или создан вручную в my.ipd, роль человека (владелец или участник), статус, дата добавления и реальное число задач. Отдельный блок «Откуда взялись проекты» объясняет состав портфеля цифрами, а проекты без задач и без связи с платформой помечаются как «Без задач», а созданные в одну секунду одинаковыми заходами у разных клиентов — как «Массовое добавление». Лишний проект можно отключить одним действием из меню «⋮»: он уходит в архив, перестаёт быть активным и попадать в отчёты и письма, но задачи и история остаются на месте, а действие обратимо.

ТЗ 249 «Спросить у ИИ — настройка показа». ИИ-агент стал управляемым: администратор может одним переключателем показать или скрыть его для всей платформы и отдельно — для любого пользователя, а сам пользователь решает, видеть ли агента в своём кабинете. В заголовке окна агента появилась шестерёнка, которая ведёт прямо в настройки. Каждое открытие агента теперь записывается, и администратор видит статистику: сколько раз открывали окно, за 7 и 30 дней, сколько человек пользуются агентом, сколько у них просмотров страниц, а также самые популярные страницы, с которых открывали агента.

ТЗ 248 «Меню, а не красная кнопка». Все разрушительные и редкие опасные действия на платформе — удаление, безвозвратное удаление, снятие и открепление, отзыв токена, ключа и ссылки, отмена отправки, отклонение заявки, завершение сессий, массовое удаление — перенесены в вертикальное кебаб-меню «⋮». Явных красных кнопок удаления в ленте не осталось: красный цвет остался только у пункта скрытого меню, где действие подтверждается дополнительным вопросом. Частые и безопасные действия (сохранить, редактировать, подробнее, одобрить, восстановить, отправить сейчас) остались обычными кнопками. Попутно устранены самодельные меню и вложенная форма тестовой отправки кампании.

ТЗ 247 «Цвет, span». Информационные статусы и сообщения об успехе переведены из зелёного в нейтральный серый: зелёные токены дизайн-системы (--green, --green-soft, --success, --success-bg, --success-solid) заменены на серые, бейджи «зелёный/жёлтый» заменены на серые, состояния «в работе», «готово», «отправлено», «в очереди», «сохранено», «проверено» во всех разделах админки, кабинета человека, гостя, мастеров синхронизации и во всех письмах стали серыми. Красный сохранён для проблем, просрочек, запретов и потерь; жёлтый — только для реального внимания и срочности; синий — для ссылок, бренда и информационных категорий. Категорийные и фирменные цвета (стадии проекта, типы событий, типы писем, источники данных, диаграммы) сохранены. Светофор в блоке «Следующий шаг» не изменялся.

Платформа переведена с цветного оформления на спокойное чёрно-бело-серое: синий больше не красит кнопки и бейджи, акцент — тёмно-серый. Цвет остался только там, где несёт смысл: красный — опасность, жёлтый — в работе, зелёный — готово, серый — нет данных. Ссылки стали синими с подчёркиванием, как в Яндексе, чтобы их невозможно было спутать с кнопкой. Исправлены статусы, которые врали цветом: завершённый проект больше не красный, активный больше не зелёный. На рабочем столе, карточке человека и карточке проекта появился блок «Следующий шаг» с одним главным сигналом и кнопкой, которая его закрывает; когда сигналов нет — прямо написано, что всё в порядке.

Человек может вести несколько проектов, и my.ipd теперь показывает их все, а не один. Страница пользователя (/admin/users/{id}) выводит все проекты человека, включая завершённые и архивные: роль, статус, этап платформы задач, дату завершения, прогресс, задачи, синхронизацию. Появился «текущий проект» — тот, по которому идут отчёты и письма: он определяется автоматически (самый свежий по дате синхронизации среди активных проектов), но администратор может выбрать проект вручную или вернуть автоматику. Закрытые проекты текущими не становятся и в отчёты и письма не попадают. Синхронизация клиента теперь забирает с платформы задач и завершённые проекты, из выгрузки читаются дата завершения и признак завершения, статус платформы «архив» больше не превращается в «активен» — это отдельный статус «В архиве». Кнопка «Проверить проекты на платформе задач» показывает, что есть на платформе у этого человека, чего нет в my.ipd, и импортирует выбранные проекты, не перезаписывая локальные названия.

Кнопка «Получить данные по проекту» на странице проекта заменена на мастер из 4 шагов (проверка данных → синхронизация → результат → готово), как мастер «Синхронизация всех людей». Направление данных показано явно на каждом шаге: импорт с платформы задач (task.ipd.test) в my.ipd в одну сторону, обратно ничего не отправляется и ничего не удаляется. Шаг 1 только читает данные (`SyncManager::previewProject`): показывает, что есть на платформе и что изменится, ничего не записывая. Шаг 2 импортирует задачи и шаги только этого проекта (`executeProject`), шаг 3 показывает счётчики и списки созданного/обновлённого, шаг 4 завершает мастер. Дополнительно исправлен подсчёт шагов в предпросмотре: шаги приходят вложенными в задачах, поэтому счётчики «шагов» на шаге 1 были всегда нулевыми.

Шаг 2 «Синхронизация» мастера «Синхронизация всех людей» стал информативнее: добавлен явный блок «Направление данных» — данные идут с платформы задач (задание: откуда сюда, куда сюда; блока нет, списки сгруппированы по типам), в верхней заметке уточнено, что именно импортировано в my.ipd в одну сторону и что обратно ничего не отправляется. Счётчик «Всего» теперь выводит сумму по объединённой статистике (включая шаги задач и людей, созданных на шаге 2), поэтому совпадает с бейджами. Таблицы «Создано» и «Обновлено» сгруппированы по типам (направления, проекты, задачи, шаги, люди) с полным числом записей, в списках показаны первые 20, у шагов — задача, у людей — email, у проектов — прогресс.

Шаг 1 «Проверка данных» мастера «Синхронизация всех людей» стал понятнее: по каждому изменённому проекту, задаче и человеку в таблице показана колонка «Что изменится» — по полям «было → станет» (станет — значение с платформы задач, оно же будет в my.ipd после шага 2); смена email подсвечена красным. Добавлены пояснения статусов («Новый» — объект ещё не в my.ipd и будет создан; «Изменён» — значение отличается, ничего не изменяется до кнопки «Следующий шаг»), таблица различий по задачам (раньше были только счётчики), в заголовках таблиц — счётчики «новых N · изменённых M» и «Показаны первые 30 из N».

Кнопка «Синхронизировать всех людей» на странице синхронизации (POST /admin/sync/all-people, «нажал — и всё пропало») заменена мастером из 4 шагов с явной площадкой-источником (task.ipd.test): шаг 1 «Проверка данных» показывает подключение к платформе, что сейчас на ней (проекты, задачи, люди, направления) и что изменится в my.ipd (новые/изменённые счётчики) — до нажатия кнопки ничего не изменяется; шаг 2 «Синхронизация» импортирует проекты, задачи и людей всех направлений (письма в мастер не входят); шаг 3 «Привязка к клиентам» — дополнительная привязка людей к их проектам (без дублей, повтор безопасен); шаг 4 «Готово» — ссылки на проекты и пользователей. В каждом шаге проактивное сообщение: что происходит сейчас, что будет дальше и что НЕ изменится до нажатия кнопки. В методологию добавлен раздел «05 Синхронизация» с правилами мастеров.

Шаг «Кого мы не добавим» мастера «Синхронизация людей» переработан: заголовок стал «Кто не будет добавлен», по каждой категории появилась ссылка на платформу задач (куда добавлять проекты и email, чтобы человек попал в экосистему), а в каждом шаге мастера появилось проактивное сообщение — что происходит сейчас, что будет дальше и что НЕ изменится до нажатия кнопки. Некритичное поле «Телефон» убрано из интерфейса: колонка не выводится в таблицах мастера, смена телефона больше не показывается и не считается изменением, хотя в базе телефон по-прежнему обновляется при импорте.

Мастер «Синхронизация людей с платформы задач» больше не тянет всех подряд: в экосистему попадают только люди с активными бизнес-проектами и электронной почтой. Люди без проектов (личные контакты/друзья) и без email на платформе задач не добавляются и не изменяются — в шаге 1 видно отдельные блоки «Кого мы не добавим» с причинами. В таблицах появилась колонка «Проекты»: видно, какие активные проекты (и стадии) у каждого человека. Экспорт платформы задач дополнен проектами людей (ид_проектов и проекты с названием, направлением, статусом, флагом «личный» и этапом), по которым мастер решает и привязывает людей к проектам.

Мастер «Экспорт людей с платформы» переименован в «Синхронизацию людей с платформы задач» — это синхронизация, а не односторонний экспорт. Шаг 1 «Проверка данных» теперь раскрашивает разницу: зелёные строки — люди будут добавлены, жёлтые — изменены (переименование/контакты), красные — смена email (критично, письма переедут на новый ящик). Каждая строка показывает ID человека на платформе задач и ID пользователя в my.ipd (сопоставление идёт по ID — имя и email могут меняться, ID стабилен), дату актуальности выгрузки платформы и дату последнего обновления записи в my.ipd.

В админке появился мастер «Экспорт людей»: люди с платформы задач (task.ipd.test) переносятся в пользователей my.ipd (/admin/users) за 4 шага — проверка данных (кто новый, у кого изменятся контакты), импорт/актуализация (создание недостающих, обновление имени, телефона, Telegram, роли и почты), привязка к проектам (pivot client_project) и итог. Смена email выполняется у той же записи клиента, поэтому история писем на старые ящики сохраняется, а новые письма уходят на актуальные адреса.

В список «Задачи с платформы задач» (/admin/tasks-platform) добавлена кнопка «Удалить все осиротевшие (N)» — разом удаляет все задачи с is_orphaned=true, которых больше нет на платформе задач. Бейдж «Нет на платформе» уточнён до «Нет на платформе задач» — теперь явно видно, что речь именно о платформе задач (task.ipd.test), а не о другой платформе.

На шаге 3 мастера после нажатия «Подготовить письма» страница раньше «зависала» на всё время подготовки (до ~10 минут) без обратной связи. Теперь при подготовке виден живой прогресс: шкала 0–100 % с обновлением по ходу работы, строка «что именно готовится» (письмо N из M: клиент — проект), счётчики обработанных и ошибок и список ошибок в реальном времени. Прогресс отдаётся потоком (text/event-stream) в том же запросе, по завершении страница сама открывает шаг 4 «Письма подготовлены».

Синхронизация с платформы задач перестала показывать клиентам служебные и устаревшие задачи: задачи, у которых нет соответствия на стороне платформы или которые исключены, помечаются «осиротевшими» (is_orphaned) и скрываются из кабинета клиента, отчётов и писем. В админке напротив такой задачи виден баннер «Нет на платформе» и действия «Вернуть»/«Удалить». Счётчики прогресса проекта пересчитываются только по видимым клиенту задачам.

Кнопка «Синхронизировать с платформы задач» на вкладке «Задачи» ведёт в мастер из 4 шагов: 1 — подключение и актуальные данные (что изменится), 2 — импорт (что заменено/изменено), 3 — выбор получателей писем об изменённых статусах задач, 4 — подготовка писем в буфер. Синхронизация выполняется только по направлениям за зону ответственности разработчика (Производство, Поддержка, сервис). Письма больше не отправляются автоматически при импорте: администратор сам решает, кому готовить, на шаге 3.

Кнопка «Синхронизировать с платформы задач» на вкладке «Задачи» ведёт в мастер из 4 шагов: 1 — подключение и актуальные данные (что изменится), 2 — импорт (что заменено/изменено), 3 — выбор получателей писем об изменённых статусах задач, 4 — подготовка писем в буфер. Синхронизация выполняется только по направлениям за зону ответственности разработчика (Производство, Поддержка, сервис). Письма больше не отправляются автоматически при импорте: администратор сам решает, кому готовить, на шаге 3.

Письма «Итоги месяца» у одного клиента выглядели одинаково (тема «Итоги месяца — имя» без указания месяца). В тему месячного письма добавлены месяц и год: «Ваш проект — итоги за Октябрь 2026». Обновлён шаблон monthly-digest в БД (ранее рассинхронизирован с сидом) и пересчитаны темы уже подготовленных в буфере месячных писем.

Подготовленные письма теперь полностью управляются прямо с рабочего стола администратора (/admin): у каждой строки «Подготовленных писем» появилось кебаб-меню (⋯) — смотреть, редактировать, копия, удалить. Удаление стало «корзиной»: письмо перемещается в корзину и его можно восстановить, а через 30 дней оно удаляется безвозвратно автоматически. В центре буфера появились вкладка «Корзина» (с счётчиком), восстановление письма, кнопка «Удалить навсегда», групповое удаление/восстановление нескольких писем сразу (чекбоксы, как в почте).

В списке «Буфер писем» (/admin/emails) у каждой карточки появилось кебаб-меню (⋯) с действиями «Смотреть», «Редактировать», «Копия» и «Удалить». Удаление теперь мягкое (SoftDeletes, deleted_at), а не жёсткий DELETE: письмо исчезает из буфера и не попадёт в рассылку, но запись остаётся в истории. Копии статистики по prepared_emails в кампаниях учитывают только неудалённые письма.

Письма — главный показатель «заботы» о клиенте. На странице пользователя в админке теперь есть явный блок «Письма и переписка»: счётчики (всего, отправлено, прочитано, в очереди/ошибки) и последние письма клиента со статусами (отправлено/ошибка/в очереди) и фактом получения (прочитано/кликнул/доставлено) — чтобы видеть переписку в 1–2 клика. В колокольчике уведомлений администратора добавлена сводка исходящих писем за сутки.

Создана полная резервная копия (code + db) по стандарту (Задание 208): архив кода, дамп БД my_ipd_local, README.md и changelog.md в папке v0.64.0. Версия 0.64.0 объединяет все изменения с момента последнего бекапа v0.60.2: задачи с платформы задач (v0.61.0), раздел «Актуальная информация» и производственная платформа (v0.62.0), дизайн письма «Актуальная информация» (v0.62.1), фикс автовхода, Total Commander (v0.63.0). Корневые README.md и changelog.md бэкапов обновлены.

Платформа выгружает переписку с клиентами в Total Commander: у каждого проекта есть свой путь в системе (tc_path), как у проектов платформы задач. В папку каждого проекта в служебную подпапку platform записывается файл «Письма.md» — все отправленные письма (журнал) и буфер подготовленных писем с датами, темой, получателем и полным видом письма. В настройках появилась вкладка «Total Commander»: видно, какие проекты имеют папку, есть ли папка на диске, сколько писем и когда была последняя выгрузка; кнопка «Выгрузить данные в Total Commander» обновляет данные во всех папках. Если платформа сломается — переписка восстанавливается из папок Total Commander.

Понедельничное письмо «Актуальная информация» переведено на общий дизайн-шаблон платформы: та же шапка «Экосистема», приветствие, карточки проектов и полноценный футер (Алексей Гапеев, реквизиты ООО «Студия ИПД», управление уведомлениями, отписка). Раньше письмо собиралось отдельным HTML (другой фон, шрифт, упрощённый футер) — теперь все письма платформы в одной экосистеме дизайна.

В платформе появился раздел «Актуальная информация» — единый взгляд на клиентов,две зоны ответственности Разработчика 2: где находится каждый проект (в производстве или на поддержке), на каком этапе конвейера, какие задачи выполняются и что планируется. Данные приходят из трёх источников экосистемы: платформа задач (task.ipd.test), производственная платформа (production.ipd.test — заказы, этапы, задачи) и локальные проекты платформы. Понедельничная рассылка «Актуальная информация» готовит письма в буфер с текущим статусом каждого проекта и планами на неделю.

В платформе появилась отдельная вкладка «Задачи» — задачи, выгруженные с платформы задач (task.ipd.test). По умолчанию показываются задачи направлений «Производство» и «Поддержка, сервис» — тех, за которые отвечает Разработчик 2; есть переключатель на все направления. На странице видна дата и время последней синхронизации, а кнопка «Синхронизировать с платформы задач» обновляет данные. По каждой задаче доступны проект, направление, статус, приоритет, срок, исполнитель и список шагов.

Приветствие во всех письмах приведено к единому правилу: если у клиента задано обращение (salutation) — используется оно, иначе имя (первое слово), но не фамилия и не полное имя. В шапке появился индикатор, на каком сайте вы работаете (тестовый/продуктовый), а подготовленные письма и журнал отправки снабжены источником и понятным временем.

Исправлен предпросмотр подготовленного письма в админке (/admin/emails/{id}): раньше панель «Предпросмотр» показывала только голое тело (body) из БД и строку-футер «Отправлено из Экосистема IPD» — без карточки Алексея Гапеева, юрданных и кнопки отписки, поэтому письмо выглядело «по-старому». Теперь страница отрендеривает настоящее письмо через ReportMail (тот же макет, что уходит клиенту, с единым футером-партиалом), и предпросмотр 1:1 соответствует реальному письму.

Футер писем приведён к единому виду во всех письмах по эталону письма 81: карточка контакта Алексея Гапеева, юридические данные и «Управление уведомлениями». Вместо трёх разных инлайн-футеров и общего партиала теперь все письма используют один общий партиал emails/partials/footer, в который добавлена рабочая кнопка отписки. Дополнительно исправлен критический баг: рассылочное письмо кампании (CampaignMail) не отправлялось вовсе из-за несовместимой сигнатуры метода with() и отсутствующей переменной $subject.

Доработан интерфейс работы с письмами. В редакторе письма появился полноэкранный предпросмотр на весь экран с переключением «Просмотр / HTML», чтобы удобно смотреть и редактировать письмо. В футер писем добавлена рабочая кнопка «Отписаться от рассылки»: по ссылке клиент отключается от рассылок без входа в систему. Вступление месячного письма переписано без «мы присылаем» — теперь оно сразу несёт ценность для получателя.

Устранено дублирование месячной рассылки: команда mail:send-monthly переведена на единый идемпотентный поток через подготовленные письма (PreparedEmail) с защитой от повторной отправки в текущем месяце. Ежемесячное письмо полностью переработано: добавлено вступление с месяцем, блок общего прогресса, списки выполненных задач и задач в работе, заметки проекта, блок о ценности и пояснение, почему клиент получил письмо.

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

Доработаны описания исторических версий: из заголовков убраны внутренние пометки «(Задание NNN)», а сам заголовок каждой версии на странице списка стал кликабельной ссылкой на её отдельную карточку. Теперь история версий читается как единый аккуратный список «что и зачем сделано».

История версий больше не хранится в единственном markdown-файле changelog.md. Каждая версия теперь — отдельная запись в базе данных со своей собственной ссылкой, что исключает потерю истории изменений.

Исправления после релиза 0.47.0.