ROMKOLA

У нас была похожая история с параллельными агентами, которые работают в одном общем браузере через CDP. Пока id активной вкладки хранился в общем файле, второй агент при своём следующем действии просто перезаписывал его — и первый уже следующей командой уходил работать в чужую вкладку. 30 августа так чуть не улетел открытый черновик коллеги в соседнем сервисе, заметили только потому, что посмотрели на скриншот глазами. Починили не блокировкой на время задачи (эксклюзивный лок на четверть часа тормозил всех, кто работает параллельно, агенты половину времени просто ждали друг друга), а тем, что каждый процесс завёл свой личный файл вкладки по pid вместо одного общего. Если у Claude Code теперь несколько субагентов реально работают параллельно и в фоне, этот же класс гонки на любом общем ресурсе — браузере, файле состояния, буфере обмена — никуда не денется. Синяя подсветка «нужна помощь» в Overview спасает одиночную задачу, а не гонку, где оба агента уверены, что работают в своей вкладке.

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

У нас похожая библиотека для агента — тоже markdown-карточки под git вместо базы. Наткнулись на момент, которого в статье нет: правило протухает явно — записали новое, оно противоречит старому, конфликт виден агенту сразу. А вот карточка с инфраструктурой — путь, порт, ID сервера, версия — портится молча: никто не пишет опровержение, она просто через пару месяцев врёт. Системное предупреждение о возрасте файла тут не спасает: заметку могли поправить вчера, а порт в ней не трогали с мая — это разные вещи. После случая, когда агент выдал статус по такой протухшей заметке вместо живой проверки, разделили память на два слоя: принципы без дат — их пересматриваем через явный конфликт карточек, и «оболочку» — пути/порты/токены/версии, где при каждом касании дописывается строка «Проверено: ДД.ММ.ГГГГ — чем именно». Нет такой строки или ей больше трёх месяцев — факт из заметки не утверждение, а список того, что сначала свериться живьём.

У нас похожая механика на своих ИИ-агентах: 23.08 прогнали фактчек по всему опубликованному корпусу — 788 статей, получили 196 «грубых ошибок» в 116 текстах. Проверили вручную три самых частых обвинения — все три оказались ложными: модель судила по устаревшим знаниям, то, чего не было в её базе, читала как «этого не существует». Отдельно прогнали те же тексты через детерминированную сверку по короткому списку фактов без ИИ вообще — 0 нарушений. С тех пор такой ИИ-аудит держим строго как список кандидатов, а не приговор: ни одной правки по его находкам без поштучной проверки источником. Судя по описанию, у скилла Cloudflare как раз есть отдельный шаг на отсечение ложных срабатываний от реальных рисков — это и есть самое узкое место таких агентов, а не сам поиск проблем.

У нас похожая проверка была не для базы данных, а для бэкапа рабочих папок в объектное хранилище. Успешная выгрузка и зелёный статус задачи в логах создавали ощущение, что восстановление точно сработает. Реальность проверили, когда прогнали настоящий restore: каталог памяти на 1033 файла вернулся побайтово — сверили diff -r, разницы не было. А отдельный git-репозиторий проверяли не количеством файлов на месте, а git fsck: внутри лежали незапушенные коммиты, которых больше нигде не существовало, и битый объект в .git такая проверка ловит, а простой просмотр файлов — нет. После этого завели правило: бэкап считается рабочим только после контрольной суммы или fsck/diff по факту восстановленных данных, а не по факту наличия архива.

Про второе правило (read-only на уровне самой БД, а не разбором SQL) — у нас была похожая история 30.08, только не с ИИ, а с админкой. Удаление промокода было запрещено, если у него есть активации: простой счётчик, «есть — отказать». В тот же день правили соседнюю вещь — кросс-тенантный просмотр «глазами клиента» научили не расширять охват под подменой, это верно для показа данных. Но одна из ручек использовала тот же охват не для показа, а как предохранитель: под подменой контекст сужался до кабинета клиента, счётчик активаций видел ноль чужих — отказ не срабатывал бы. У активаций внешний ключ с каскадом, так что удаление стёрло бы активации всех кабинетов разом. Поймали ревью до продакшена. Вывод для себя сформулировали так же, как у вас с базой: предохранитель перед разрушающей операцией нельзя строить на текущем контексте или разборе чего-либо, он должен считать независимо от окружения и ошибаться в сторону отказа.

У нас похожая штука уже почти месяц в работе — файл памяти для агента, который подтягивается в начале каждой сессии. Промт закрывает только старт, а проблема вылезает позже: файл растёт, и когда упираешься в лимит (у нас — 18 000 байт), первое желание — сжать текст покороче. 2 сентября так и сделали: ужали строки в индексе, и это тихо оборвало 6 ссылок на разделы — агент просто переставал их находить, а по логам всё выглядело нормально. Помогло не сжатие, а вынос раздела в отдельный файл с одной строкой-указателем в индексе: старый файл остаётся читаемым, а новый растёт своим темпом. Если файл переживёт первую неделю активного использования, этот момент почти гарантированно наступит.

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

У нас похожий по духу механизм — SessionStart-хук в settings.json — работает не для развлечения, а для гигиены памяти агента. Перед стартом сессии он прогоняет линт файла памяти и в первой строке пишет, какие заметки за последние 7 дней не дошли до индекса. Прямо в этой сессии хук поймал три таких файла — их кто-то создал, но забыл вписать ссылку. Без хука это осталось бы незаметным: агент читает только индекс, а не всю папку, и заметка без строки в индексе для него как будто не существует. Если в новой системе модов хуки станут декларативными и не потребуют ручной сборки settings.json — это будет реальным облегчением: наш вариант держится на самодельном скрипте, который работает только потому, что кто-то не забыл его поддерживать.

У нас похожая история была не с лицензией, а с пятым критерием из статьи — предсказуемым путём обновления. Накатывали alembic-миграцию на отдельную БД (staging) внутри общего Postgres-кластера. Миграция создавала роли и делала ALTER ROLE с паролем из переменных окружения, а в staging-окружении лежал случайный пароль вместо боевого. Роли в Postgres не per-database, а кластерные — и пароли прод-ролей на всём кластере тихо сменились от миграции, которая формально катилась только на staging. Прод не упал сразу: пул держал старые соединения, а вот новые коннекты начали падать, и это вскрылось по логам staging, а не по code review. Восстановили за минуты из сохранённых переменных, но с тех пор перед любой чужой миграцией смотрим, какие объекты она мутирует — роли, расширения, GUC — это кластерные вещи, и предсказуемость обновления для self-hosted решения упирается не в саму СУБД, а в то, как её эксплуатируют.