Два агента получили части одной задачи: первый добавляет поле к статье, второй выводит его на странице. Оба открыли контроллер, оба поправили передаваемые данные. Даже если Git соединит изменения без конфликта строк, один исполнитель может использовать имя поля, которое другой уже заменил.
Каталоги помогают распределить работу, но граница папки сама по себе не задаёт договорённость. Для совместного изменения нужны владелец каждого общего файла и явное описание данных, которые переходят между частями. Разберём это на условном добавлении короткой подписи источника к публикации.
Опишите контракт до параллельной работы
Предположим, редактор должен указывать подпись источника в админке, а читатель — видеть её под заголовком. До делегирования нужно решить: поле необязательное или обязательное, допускает ли HTML, что показывать при пустом значении, как обрабатывать старые записи. Это продуктовые решения, их нельзя оставлять двум исполнителям для независимого угадывания.
Для примера выберем необязательную текстовую подпись без HTML. Старые статьи остаются без неё, пустое значение не создаёт пустую строку на странице. Такой выбор достаточен, чтобы отделить хранение от отображения. Название поля тоже фиксируем заранее — иначе согласование переносится на момент интеграции.
Поле: source_label, необязательный обычный текст.
Старые записи: значение отсутствует, заполнение не требуется.
Публичный вывод: только непустая подпись; HTML экранируется.
Админка: редактор может заполнить и очистить поле.
Контракт готов, когда поле доступно модели и передаётся в существующем Post.
Изменение имени или типа возвращается владельцу общей задачи.Назначьте владельцев файлов
Первому исполнителю можно отдать миграцию, модель и форму админки. Второму — публичный шаблон и связанные проверки отображения. Контроллер остаётся у первого, если там действительно нужна правка. Если модель уже целиком приходит в шаблон, менять контроллер ради нового поля не требуется.
Фраза «работай только с фронтендом» здесь слабее списка конкретных путей. Форма Filament тоже интерфейс, но в этой задаче относится к первой части. Я бы описывал границу через результат и файлы: «обеспечить хранение и редактирование source_label», а не через должность.
Право читать соседнюю зону полезно сохранить. Исполнитель шаблона должен проверить, как в проекте экранируется обычный текст и как устроен объект статьи. Ограничение владения запрещает ему незаметно править чужую часть, а не понимать её. Найденное противоречие возвращается владельцу с конкретным примером.
Выберите способ изоляции
В общей рабочей папке изменения видны всем сразу. Это удобно для небольшого согласованного изменения, но делает опасными глобальное форматирование и команды, меняющие множество файлов. Перед запуском нужно узнать, не работает ли соседний исполнитель в тех же путях. Неизвестный diff нельзя объявлять мусором и откатывать.
Отдельные рабочие деревья Git разделяют рабочие каталоги. Документация git worktree описывает несколько рабочих деревьев, связанных с одним репозиторием. Такой вариант удобен, когда две части действительно можно реализовать независимо. Однако он не разделяет автоматически общую базу, Docker-тома или внешние сервисы.
Поэтому к каждому дереву нужен понятный способ проверки. Если обе команды тестов очищают одну тестовую БД, изоляция исходников проблему не решит. Либо выдайте отдельные тестовые окружения, либо выполняйте такие проверки последовательно. Рабочую базу проекта для этого не используйте.
Передавайте готовую часть вместе с ограничениями
Ответ «модель готова» недостаточен. Получателю нужны изменённые пути, согласованное имя поля, способ проверки и то, что ещё не проверялось. Если миграция пока только написана, нельзя представлять её как применённую. Если тест использовал новую пустую базу, он ничего не говорит о сохранности существующих статей.
Передача части хранения:
- добавлено source_label с возможностью пустого значения;
- существующие записи не заполняются автоматически;
- форма позволяет сохранить и очистить подпись;
- публичный шаблон не изменён;
- приложены команды проверок и фактический вывод;
- отдельно указан статус проверки обновления непустой базы.Это шаблон отчёта, который заполняется по факту. Не копируйте все пункты в «выполнено», если соответствующего действия не было. Второй исполнитель должен иметь возможность проверить контракт до начала своей правки.
Проверяйте объединение как отдельное изменение
Успех двух локальных наборов тестов не гарантирует успех объединённого результата. После соединения частей пройдите сквозной сценарий: старую статью можно открыть, новую подпись можно сохранить, она появляется на странице, очистка убирает строку. Значение с угловыми скобками должно отображаться как текст, если именно это было выбрано.
Проверьте и отрицательный случай: пустая подпись не ломает отступы и не добавляет лишний заголовок. Эти условия относятся к стыку хранения и вывода, поэтому они могут остаться без владельца, если каждый смотрит только на свою папку.
Назначьте одного ответственного за сборку результата. Он проверяет общий diff, повторяет согласованные сценарии и сообщает человеку оставшиеся ограничения. Если контракт меняется в середине работы, сначала обновляется договорённость, затем обе части. Параллельность полезна до тех пор, пока она не заставляет исполнителей молча принимать разные решения об одной системе.
