Владелец объявил закрытыми обе телеграм-ветки и велел свести их вместе,
ювелирно и ничего не потеряв. Ветка робота несла 9 коммитов, которых
у меня не было, и трогала 79 файлов.
Конфликта три:
- app/tests/Frontend/advertising-channels.spec.ts — настоящий, в коде.
Обе стороны сторожили одно: у кого есть настоящий экран, а кто заглушка.
Моя перечисляла живые площадки прямо в тесте, версия робота берёт их
из общего списка REAL_ROUTES наверху файла и вдобавок проверяет, что
заглушки вообще остались. Проверил список: там и Яндекс, и Телеграм —
покрытие то же, проверка сильнее. Взял версию робота, файл вышел байт
в байт как у него. Сторож прогнан отдельно, зелёный;
- app/phpstan-baseline.neon — машинный, пересобран заново по проектной
процедуре в два шага, phpstan.neon возвращён на место, итог 0 ошибок;
- docs/observer/STATUS.md — машинный файл наблюдателя, взята своя версия,
его всё равно переписывает хук.
Доказательство, что ничьё не пропало — сверкой, а не на слово:
- файлов, где результат отличается от версии робота, а я их НЕ трогал:
ноль. То есть ни одна его правка не откатилась молча;
- файлов, отличающихся от main: 79, и все 79 объясняются нашей работой.
Необъяснённых ноль — значит чужая работа из main не затёрта.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Мой коммит уехал в main отдельно — пересадкой на актуальную вершину
и оттуда на боевой. Возвращаю main к себе, чтобы ветка не разъезжалась.
Пришло 9 коммитов, из них главное — работа соседней сессии по воронке
продаж, уже влитая в main и запушенная.
Конфликта два, оба в общих машинных файлах:
- cspell-words.txt — сторону не выбирал, объединил. Все слова обеих
сторон на месте; убрана ровно одна строка — мой же дубль «админский»,
который прошлый коммит добавил дважды. Проверено сравнением с версией
до слияния: другого отличия нет;
- docs/observer/STATUS.md — машинный файл наблюдателя со столбиком часов
процессов, взята своя версия, его всё равно переписывает хук.
Замечание на будущее: патч «минимум площадки считается по длине периода»
живёт в двух коммитах — 948807507 у меня и в ветке робота, 9df7846fd
в main. В main уехала только вторая копия, main чист. Когда моя ветка
и ветка робота пойдут в main, git встретит этот патч второй раз.
Статанализ остановил слияние, и это была НЕ ложная тревога: файл-эталон
phpstan-baseline.neon склеился из двух версий и перестал соответствовать
коду. Все 16 ошибок — в чужих файлах воронки продаж, пришедших из main
байт в байт, известного ложного класса про Pest. Эталон из main один
не подошёл: всплыли записи, нужные этой ветке. Пересобрал по проектной
процедуре в два шага, phpstan.neon вернул на место. Итог 0 ошибок,
правка эталона мелкая: +43 -31. Моих файлов среди добавленных записей
нет ни одного.
Co-Authored-By: Claude Opus 5 (1M context) <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>
(cherry picked from commit 975175750a)
Кампания 713175197 третьи сутки не показывалась при замороженных у клиента
деньгах, а программный интерфейс на всех уровнях рапортовал «Идут показы».
Правду отдала только подпись на экране кабинета: «Для показа в заданных
регионах предоставьте документы» — 13 объявлений придержаны, 2 отклонены.
1. Яндекс отвечает машине ПО-АНГЛИЙСКИ, если не попросить русский.
Замер боевым ключом, два одинаковых запроса подряд: без заголовка
«Rejected at moderation.», с Accept-Language ru «Отклонено на модерации.».
Английская строка уезжала клиенту в переписку и письмом как пояснение
модератора, честная заглушка «причину выясняем» не срабатывала никогда,
а на следующем обходе английская строка ложилась ПОВЕРХ доклада разведчика
— проверено по боевой ленте: 30.07 в 15:02 робот принёс полную причину,
в 17:00 её накрыло. Лечение: спрашиваем язык явно плюс второй заслон —
английские отписки узнаются как отписки.
2. Отказ включения Яндекс кладёт в Warnings, а код смотрел только в Errors.
Ответ целиком: ResumeResults с Warnings 10201 «Объявление не остановлено»
при пустом Errors. Исключения нет, портал считал, что справился: двое суток
обход каждые два часа поднимал 13 объявлений, ноль записей в журнале.
Лечение: resumeAds возвращает, кого включить не дали.
3. Новый исход «принято, но придержано» порталу не был известен вовсе.
Вердикт ACCEPTED, ярлыка «Отклонено» нет, разведчик не ходил — клиент видел
«Идут показы» при нулевых показах. Теперь по отказу включения клиенту идёт
сообщение «Яндекс принял объявление, но пока не показывает его. Причину
выясняем» — текст выбран владельцем — и туда же едет разведка.
Ловушка, обойденная по дороге: включение спрашиваем ДО разбора объявлений.
Наоборот — сообщение о придержке легло бы поверх доклада разведчика, и обход
начал бы чередовать их по кругу: защита от дублей смотрит на последнее сообщение.
Замеры. Восемь новых сторожей, все написаны ДО починки и падали именно
на живых данных. Отдельный сторож на противоположный случай — включённому
объявлению разведку не заводим — был зелёным с самого начала.
Портал 4083 теста, 4043 прошло, 16 упало: те же шесть давних классов и ровно
те же числа, что до работы, было 4069/4029/16. Плюс 14 тестов — ровно новые.
Pint и Larastan по изменённым файлам чистые.
Главный урок записан в cabinet-flow.md §7.9: в §7.7 лежит правдивый РУССКИЙ
ответ Яндекса, снятый ДРУГИМ инструментом, который язык просил. Разбор отписок
построили по показаниям прибора, которым продукт не пользуется. Мерить надо той
же дорогой, по которой ходит боевой код.
На боевой НЕ выкатывалось.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Кампания 713175197 третьи сутки не показывалась при замороженных у клиента
деньгах, а программный интерфейс на всех уровнях рапортовал «Идут показы».
Правду отдала только подпись на экране кабинета: «Для показа в заданных
регионах предоставьте документы» — 13 объявлений придержаны, 2 отклонены.
1. Яндекс отвечает машине ПО-АНГЛИЙСКИ, если не попросить русский.
Замер боевым ключом, два одинаковых запроса подряд: без заголовка
«Rejected at moderation.», с Accept-Language ru «Отклонено на модерации.».
Английская строка уезжала клиенту в переписку и письмом как пояснение
модератора, честная заглушка «причину выясняем» не срабатывала никогда,
а на следующем обходе английская строка ложилась ПОВЕРХ доклада разведчика
— проверено по боевой ленте: 30.07 в 15:02 робот принёс полную причину,
в 17:00 её накрыло. Лечение: спрашиваем язык явно плюс второй заслон —
английские отписки узнаются как отписки.
2. Отказ включения Яндекс кладёт в Warnings, а код смотрел только в Errors.
Ответ целиком: ResumeResults с Warnings 10201 «Объявление не остановлено»
при пустом Errors. Исключения нет, портал считал, что справился: двое суток
обход каждые два часа поднимал 13 объявлений, ноль записей в журнале.
Лечение: resumeAds возвращает, кого включить не дали.
3. Новый исход «принято, но придержано» порталу не был известен вовсе.
Вердикт ACCEPTED, ярлыка «Отклонено» нет, разведчик не ходил — клиент видел
«Идут показы» при нулевых показах. Теперь по отказу включения клиенту идёт
сообщение «Яндекс принял объявление, но пока не показывает его. Причину
выясняем» — текст выбран владельцем — и туда же едет разведка.
Ловушка, обойденная по дороге: включение спрашиваем ДО разбора объявлений.
Наоборот — сообщение о придержке легло бы поверх доклада разведчика, и обход
начал бы чередовать их по кругу: защита от дублей смотрит на последнее сообщение.
Замеры. Восемь новых сторожей, все написаны ДО починки и падали именно
на живых данных. Отдельный сторож на противоположный случай — включённому
объявлению разведку не заводим — был зелёным с самого начала.
Портал 4083 теста, 4043 прошло, 16 упало: те же шесть давних классов и ровно
те же числа, что до работы, было 4069/4029/16. Плюс 14 тестов — ровно новые.
Pint и Larastan по изменённым файлам чистые.
Главный урок записан в cabinet-flow.md §7.9: в §7.7 лежит правдивый РУССКИЙ
ответ Яндекса, снятый ДРУГИМ инструментом, который язык просил. Разбор отписок
построили по показаниям прибора, которым продукт не пользуется. Мерить надо той
же дорогой, по которой ходит боевой код.
На боевой НЕ выкатывалось.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Первая редакция промта вела следующую смену прямо в аварию: шаг «выкат файлов»
без единой проверки, насколько ветка отстала от основной. На 01.08 отставание
было 7 коммитов, и это блок менеджеров на боевом. Залей папку целиком - и
воронка продаж с корзиной и фильтрами исчезла бы с боевого сайта.
Вписано правило замера: правое число в git rev-list --left-right --count
обязано быть 0 перед выкатом, иначе сперва сведение и повторный прогон.
Отмечено, что основная продолжает двигаться, и сведение надо повторять
непосредственно перед выкатом, а не заранее.
Дописаны две ловушки. Первая: столкновение номеров журнала схемы git НЕ
показывает как конфликт, молча склеивает две записи с одним номером - дан
готовый датчик на дубли. Вторая: фронтовый набор был красным пять дней, потому
что его не гоняли целиком, - велено гонять vitest целиком, а не по файлу.
Пункт про журнал схемы переписан с «дописать v9.31» на «сделано, номер v9.32».
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Первая редакция промта вела следующую смену прямо в аварию: шаг «выкат файлов»
без единой проверки, насколько ветка отстала от основной. На 01.08 отставание
было 7 коммитов, и это блок менеджеров на боевом. Залей папку целиком - и
воронка продаж с корзиной и фильтрами исчезла бы с боевого сайта.
Вписано правило замера: правое число в git rev-list --left-right --count
обязано быть 0 перед выкатом, иначе сперва сведение и повторный прогон.
Отмечено, что основная продолжает двигаться, и сведение надо повторять
непосредственно перед выкатом, а не заранее.
Дописаны две ловушки. Первая: столкновение номеров журнала схемы git НЕ
показывает как конфликт, молча склеивает две записи с одним номером - дан
готовый датчик на дубли. Вторая: фронтовый набор был красным пять дней, потому
что его не гоняли целиком, - велено гонять vitest целиком, а не по файлу.
Пункт про журнал схемы переписан с «дописать v9.31» на «сделано, номер v9.32».
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Владелец спросил, не потрём ли мы соседнюю смену. Проверил - потёрли бы.
Наша ветка отстала от основной на 7 коммитов, и это ровно сегодняшняя работа
по воронке продаж: корзина, журнал движений карточки, фильтр по датам, дробь
у Отказа. Выкат по плану был ПОЛНЫЙ заливкой файлов - боевой сайт получил бы
портал без всего этого. Соседи выкатывали точечно, шестью файлами, поэтому
у них и не рвануло.
СТОЛКНОВЕНИЕ НОМЕРОВ ЖУРНАЛА СХЕМЫ, ТРЕТИЙ РАЗ ЗА СУТКИ. Час назад я записал
v9.31 за заголовок объявления. В это же время соседи записали v9.31 за корзину
воронки и влили в основную. Обе записи настоящие. Git конфликта НЕ ПОКАЗАЛ -
просто склеил две записи с одинаковым номером в один файл, молча. Наша
подвинута на v9.32, боевая осталась на своём номере.
Пересобран список исключений статанализа: после сведения он врал счётчиком
90 против 95 и не знал новых файлов соседей. Проверено, что пересборка ничего
настоящего не спрятала - все 16 замечаний были одного вида, ложная тревога
PendingCalls, плюс одно про форму данных внутри задания робота, тоже в тесте.
ПОЧИНЕН ВРУЩИЙ СТОРОЖ ВИТРИНЫ РЕКЛАМНЫХ КАНАЛОВ. Тест утверждал, что настоящий
экран есть только у Яндекса, а Телеграм получил свой ещё 27.07 - сторож пять
дней держал фронтовый набор красным, и этого никто не видел, потому что фронт
целиком не гоняли. Список настоящих каналов ведётся руками намеренно: смысл
сторожа - поймать случайно прописанный маршрут у канала-заглушки.
Приёмка сторожа вырезанием: на честном коде проходит, на подложенном маршруте
для ВК падает, после возврата снова проходит. Файл каналов вернулся байт в байт.
Замеры после сведения:
- портал 4091 тест, 4087 прошло, 0 падений, 0 ошибок
- фронт 232 файла, 1739 тестов, 0 падений
- статанализ 0 замечаний
- робот 130 из 130
На бой ничего не выкачено. Боевой сайт не тронут.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
По правке владельца со скрина: блок фильтра по датам переехал из отдельной
строки под заголовком в общий ряд справа — к «Менеджер» и «Происхождение».
Порядок внутри блока перевёрнут: САМ ФИЛЬТР крайний справа, СРОК левее него.
Читается справа налево: «что менялось» → «вчера».
Ряд получил flex-wrap: на узком экране переносится, а не уезжает за край.
На экране менеджера тот же ряд — экраны не должны разъезжаться.
Порядок закреплён тестом, иначе его снова переставят.
Перед слиянием с main я откатил 4 файла к своей старой версии, чтобы
сдвинуть с места застрявшее слияние — и слияние закрепило этот откат.
Пострадала починка от 29.07: чтение связок поставщика из pivot (без неё
5 из 9 работающих проектов показывали жёлтое «Готовим к запуску» при
живом заказе) и два набора тестов вебхука/сверки CSV.
Файлы возвращены к состоянию main 7361d1ae3. На боевой откат НЕ уезжал —
выкат был точечный, только 6 файлов воронки продаж; проверено на живом
сервере: починка там на месте.
Владелец решил катить. Промт написан под это, а не под хвосты.
Главное, что вскрылось при подготовке: работа разошлась по ДВУМ веткам, и ни
одна не содержит другую. У соседней ветки tg-zagolovok нет наших трёх правок
тестов от 01.08, у нас нет их заголовка объявления. Обе от основной не
отстают. Поэтому первый шаг смены - свести ветки, иначе выкатим половину.
Выкат намеренно разрезан надвое. Портал можно катить сразу: переключатель
остаётся в старом положении, поведение не меняется, новые таблицы и канал
уезжают спящими. Робота включать некуда, пока не решено, на какой машине он
живёт - МТС не пускает адреса дата-центров, это упирается в обращение 31074.
В промте прописаны обязательные пред-полётные: журнал схемы для их миграции
записью v9.31 - её нет вообще, а это то самое правило, из-за нарушения
которого ночью столкнулись номера; пересборка списка исключений статанализа
после сведения; проверка их нового теста на добавленный запрет выхода
в интернет; ПЕРЕзапуск service_bypass_policies, иначе канал робота увидит
ноль заданий молча.
Приёмка - глазами в кабинете МТС, а не по журналу портала. Добавлены две
находки для владельца, ничего не тронуто, и одиннадцать ловушек.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Владелец решил катить. Промт написан под это, а не под хвосты.
Главное, что вскрылось при подготовке: работа разошлась по ДВУМ веткам, и ни
одна не содержит другую. У соседней ветки tg-zagolovok нет наших трёх правок
тестов от 01.08, у нас нет их заголовка объявления. Обе от основной не
отстают. Поэтому первый шаг смены - свести ветки, иначе выкатим половину.
Выкат намеренно разрезан надвое. Портал можно катить сразу: переключатель
остаётся в старом положении, поведение не меняется, новые таблицы и канал
уезжают спящими. Робота включать некуда, пока не решено, на какой машине он
живёт - МТС не пускает адреса дата-центров, это упирается в обращение 31074.
В промте прописаны обязательные пред-полётные: журнал схемы для их миграции
записью v9.31 - её нет вообще, а это то самое правило, из-за нарушения
которого ночью столкнулись номера; пересборка списка исключений статанализа
после сведения; проверка их нового теста на добавленный запрет выхода
в интернет; ПЕРЕзапуск service_bypass_policies, иначе канал робота увидит
ноль заданий молча.
Приёмка - глазами в кабинете МТС, а не по журналу портала. Добавлены две
находки для владельца, ничего не тронуто, и одиннадцать ловушек.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Промт следующей смене врал в самом громком месте: хвост Н1 был записан как
срочный - "похоже, протух боевой ключ Яндекс Директа". Это оказалось ложной
тревогой, и написал её я сам, не проверив трёх фактов, опровергающих её
за пять минут. Ключ в тесте подставной, локально боевого ключа нет вовсе,
а в Яндекс тест ходил потому, что подбирал чужое задание из базы.
Раздел Н1 переписан: пометка "закрыт, тревога ложная", разбор настоящей
причины и урок про слово "срочно" в промте. Раздел Х4 помечен закрытым -
тест внешних сервисов больше не зависит от сети.
В Х2а вписан готовый датчик поиска файла, который гадит в базу, и ловушка
про то, что искать уборку словом нельзя. В Х2б у "чужого писателя" появилось
имя - параллельная смена в папке tg-zagolovok, она ходит в общую базу.
Добавлены две находки для владельца, ничего не тронуто: ночная сборка слепка
падает целиком от одного проекта без источника лидов, и начальник отдела
при запросе всего отдела видит всех клиентов системы.
В ловушки дописан запрет на выход в интернет из тестов с пояснением, почему
его нельзя снимать.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Промт следующей смене врал в самом громком месте: хвост Н1 был записан как
срочный - "похоже, протух боевой ключ Яндекс Директа". Это оказалось ложной
тревогой, и написал её я сам, не проверив трёх фактов, опровергающих её
за пять минут. Ключ в тесте подставной, локально боевого ключа нет вовсе,
а в Яндекс тест ходил потому, что подбирал чужое задание из базы.
Раздел Н1 переписан: пометка "закрыт, тревога ложная", разбор настоящей
причины и урок про слово "срочно" в промте. Раздел Х4 помечен закрытым -
тест внешних сервисов больше не зависит от сети.
В Х2а вписан готовый датчик поиска файла, который гадит в базу, и ловушка
про то, что искать уборку словом нельзя. В Х2б у "чужого писателя" появилось
имя - параллельная смена в папке tg-zagolovok, она ходит в общую базу.
Добавлены две находки для владельца, ничего не тронуто: ночная сборка слепка
падает целиком от одного проекта без источника лидов, и начальник отдела
при запросе всего отдела видит всех клиентов системы.
В ловушки дописан запрет на выход в интернет из тестов с пояснением, почему
его нельзя снимать.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- 12-я колонка «Корзина», результат «В корзину» просит только причину;
- в шапке «Отказа» дробь «4/2» с подсказкой «из них 2 после ручного
тестирования»; при нуле дробь не рисуется — «69/0» это шум;
- у «Выслано КП» поле даты подписано «если договорились» и необязательно;
- орган фильтра по датам на ОБОИХ экранах, два режима + период.
Приёмка глазами пройдена живьём по всем семи пунктам, включая «Воронку отдела»
(снимки в docs/superpowers/screens/2026-08-01-korzina-filtry/priemka/).
Браузер поймал то, чего не видели тесты: при смене режима оставался прежний
период, и «что менялось за завтра» давало пустую доску — теперь период
возвращается к «Сегодня», на это заведён отдельный тест.
Прогон: сервер 1245/1245, фронт 1567/1567. Журнал схемы — v9.31.
Полный набор стал зелёным целиком: 4063 теста, 0 падений и 0 ошибок против
36 непроходящих до правок. Рабочий код не тронут - изменены только тесты.
Корень у пяти правок один: тест зелёный, а после себя оставляет мусор в базе,
и падают соседи. Три файла рекламы писали набело, без отката. Их записи -
задание роботу и проекты без источника лидов - переживали тест, и дальше
в том же прогоне их подбирали чужие проверки. Отсюда 16 падений в файле
про робота креативов и 13 в файлах про ночной слепок.
Тестам запрещён выход в интернет - Http::preventStrayRequests в TestCase.
До этого прогон физически ходил в живой кабинет Яндекс Директа, а поломка
маскировалась под "Invalid OAuth token", хотя ключ в тесте подставной.
Сторож принят вырезанием: со снятой правкой та же поломка называет себя
честно, с адресом запроса.
Он же вскрыл, что ProjectRuleNotificationTest слал живой запрос на удаление
проекта в кабинет поставщика crm.bp-gr.ru, оставаясь зелёным - ответ кабинета
тест не проверяет. Поставлена заглушка.
ExternalServiceDownAlertTest избавлен от зависимости от сети - закрыт хвост,
тянувшийся с 30.07: падал в общем прогоне, проходил в одиночку.
InAppNotificationTest брал первую попавшуюся запись во всей таблице вместо
своей. SalesOverviewTest попадал в топ-4 клиентов по удаче: при запросе
всего отдела отбор не ограничен ничем, все тенанты базы с нулём лидов равны.
Клиенту даны настоящие лиды - место в четвёрке заслуженное.
Проверено: полный прогон 4063/4059 зелёный, статанализ 0, код-стиль моих
файлов чисто. На бой ничего не выкачено.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Влил fix/robot-yandex-zamok (26 коммитов: сведение с основной, стадии воронки
«Тестирование ручное» и «Выслано КП», чтение вердикта и пересдача по опросу)
в ветку заголовка объявления.
Конфликт был один — docs/observer/STATUS.md, машинный файл наблюдателя
со столбиком часов процессов. Взята своя, более свежая версия; файл всё равно
перезаписывается хуком.
Замер после слияния (своя тестовая база liderra_testing_zag, прогон в тишине):
портал 4069 тестов, 4029 прошло, 16 упало; робот 130/130.
До слияния было 4063/4018/17. Тестов больше, падений меньше — стык чистый.
Падают шесть давних классов, не связанных с этой работой: CreativeRobotEndpoint
(11 — лезет в живой Директ и получает «недействительный ключ»), CreativeJobService,
InAppNotification, PhoneRegionSmoke, ProjectExtensions, SalesOverview.
Проверено отдельно: таблица заданий роботу не ограничивает список режимов
(обычная строка), поэтому новые «read-status» и «resubmit» миграции не требуют.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Дмитрий