Несколько агентов, один репозиторий: правила владения из реальных инцидентов

👥 Что идёт не так

Один агент на репозитории ведёт себя как один аккуратный коллега. Несколько агентов — как несколько коллег, одновременно правящих один документ без подписей. Случаются три вещи. Они затирают друг друга. Коммит захватывает чужое полусделанное изменение. А потом никто не может сказать, кто что изменил, и причину не устранить.

📅 Два инцидента

21 сентября 2026 агент записал устаревшую копию общего управляющего файла поверх свежей. В файле лежал реестр идущих инициатив. Он потерял пятнадцать ключей и три записи конвейера, включая ссылку на принятое архитектурное решение.

26 сентября 2026 два агента одновременно правили одно временное рабочее дерево. Коммит одного из них захватил бы незавершённые изменения другого. Второй агент ещё и сменил владельца папки, что сломало прогон тестов первого.

📐 Правила, которые мы написали

1. Одно рабочее дерево на агента. Каждый агент создаёт свою папку с именем из себя и задачи и кладёт в неё маленький файл владельца: агент, номер процесса, время, задача. Увидели файл владельца не вашего — остановитесь и скажите человеку.
2. Только явные пути. Добавляйте файлы по имени. «Добавить всё» не используйте никогда: в общем дереве всегда лежат чужие изменения.
3. Управляющие файлы правят по одной записи. Перечитайте файл непосредственно перед записью. Если инструмент не умеет точечной правки, верните предлагаемый текст владельцу, а не пишите файл целиком.
4. У каждой инициативы есть владелец. Реализует владелец. Остальные предлагают изменения в отчёте.
5. Заканчивайте коммитом. Изменение, оставшееся незакоммиченным в общем дереве после задачи, — дефект: его никто не примет, чужой коммит может его захватить или оно потеряется.

🧪 Тест на «худеющие» файлы

Потерю 21 сентября поймал бы дешёвый тест. Наш сравнивает управляющие файлы в рабочем дереве с закоммиченной версией и падает, если запись, бывшая в коммите, исчезла. Сообщение об ошибке начинается с фиксированного слова, чтобы его было легко искать. В файле теста 4 теста, и он идёт в ночных воротах.

🛠️ Практика: настройте за час

1. Создавайте рабочее дерево на агента скриптом, который заодно пишет файл владельца.
2. Сделайте так, чтобы «добавить всё» падало: обёртка или pre-commit проверка выводит добавляемые пути и просит назвать каждый в задаче.
3. Выберите три файла, которые управляют вашей системой: реестр, список конвейеров, конфигурацию. Запишите их.
4. Напишите тест, который загружает каждый из коммита и из дерева и падает, если ключ или запись пропали.
5. Добавьте поле владельца в каждую инициативу.
6. Добавьте правило: задача не закончена, пока нет коммита и push.

✅ Проверьте себя

• Запустите двух агентов на двух задачах. Их папки разные, в каждой лежит файл владельца.
• Удалите запись из управляющего файла и запустите тест. Он падает и называет запись.
• Попробуйте добавить всё. Проверка останавливает вас и показывает, что увидела.
• По окончании задачи git status в общем дереве не показывает ничего вашего.

🚧 Когда это не работает

• Конфликты слияния остаются. Отдельные деревья переносят конфликт на слияние. Правило владельца удерживает его маленьким.
• Генерируемые файлы. Файлы, которые перегенерирует каждый агент, будут конфликтовать всегда. Выведите их из git или сериализуйте.
• Диск и сборка. Каждому дереву нужны место и сборка. Для лёгких задач используйте неглубокие копии.
• Агенты, игнорирующие инструкции. Правило в файле — не принуждение. Важное переносите в проверки.
• Правки людей. Люди, пишущие в общее дерево, ломают модель. Дайте им тоже своё дерево.

📊 Доказательства

➡️ Дальше

Как делить работу между агентами, читайте в Делить работу между агентами — и когда не стоит, а как передавать работу с критериями — в Разработке по спецификации.

Источники

• Делить работу между агентами — и когда не стоит: устройство роя.
• Разработка по спецификации на готовых пакетах задач: передача с критериями.
• AGENTS.md и файлы правил: где живут правила.
• Политика и реестр использования ИИ: владение в реестре.