Как агенты теряли чужие правки

Агент сохранял свои изменения в общей таблице. Вместе с этим из неё исчезали записи других участников.

Так несколько раз произошло в эксперименте Рината Абдуллина. Агенты дорабатывали программу для задач интернет-магазина, а в LANES.md записывали, кто какое направление взял, какие части кода меняет и в каком состоянии работа. Потерять строку здесь — потерять часть сведений о том, кто чем занят.

22 октября агент lea-code опубликовал расследование: он сравнил строки в последних 30 версиях таблицы и указал на три сохранения china-brother, после которых пропадали чужие записи.

Почему обновление не помогло

China-brother ответил и признал причину. Когда сервис сообщал о конфликте, он обновлял состояние, читал свой черновик и передавал его целиком как результат разрешения конфликта.

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

Даже сравнение исходной копии со своим черновиком не показывало проблему. Обе версии были сделаны до появления чужих строк. Чужих добавлений не было ни в одной из них.

По собственному ответу china-brother, три его сохранения сработали именно так. Технически конфликт разрешён, но общий документ потерял данные.

Что изменили

Lea-code сообщил о восстановлении нескольких записей и добавил в начало таблицы правило: сначала обновить состояние, затем менять или добавлять отдельные строки. Не заменять весь файл копией, прочитанной раньше.

China-brother принял этот порядок. Если другой участник успел сохранить изменения, он предложил заново сделать свою точечную правку на свежей версии. Тот же подход — для общего README и файлов ролей.

Это было изменение способа работы, записанное участниками. Автоматического запрета на опасную перезапись этот кейс не подтверждает.

Что удалось проверить

При нашем разборе мой агент отдельно сравнил версии 78 и 79 таблицы. Во второй исчезли три идентификатора направлений: i2c-port-on-89, listed-sku-refs-on-89 и llm-5xx-retry.

В более позднем срезе все три идентификатора снова нашлись в файле. А в версии 168 мы отдельно проверили наличие правила точечного редактирования.

Получилась цепочка: lea-code описал потерю, china-brother признал механизм и принял новый порядок, наша проверка подтвердила исчезновение конкретных записей и их последующее наличие.

Но мы не сверяли восстановленные строки посимвольно и не проверяли, прекратились ли такие потери после нового правила. Поэтому сказать «рой починил общую память» было бы слишком сильно.

Как применить у себя

Если несколько агентов меняют одну заметку, я бы оставил им такой порядок:

1. Перед записью открыть актуальную версию и прочитать изменения в нужном разделе.
2. Внести свою правку в этот участок, сохранив соседние записи.
3. При конфликте заново свериться с общей версией. Свой старый черновик не считать готовым объединением.
4. После сохранения перечитать результат: появилась ли своя правка и остались ли чужие изменения.

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

Источники

Эпизод 22 октября 2026 года; наша проверка — по сохранённым материалам 23 октября. Текст подготовлен 5 ноября. Более поздние изменения таблицы и соблюдение правила для него не проверялись.

• Расследование lea-code, d4426.
• Ответ china-brother с признанием причины и новым порядком, d4446.
• LANES до потери, версия 78, и после неё, версия 79.
• LANES с правилом точечного редактирования, версия 168.

Ссылки ведут в BitGN Brain. При проверке сервера 5 ноября он отвечал HTTP 503; текст опирается на сохранённые источники.