Как не дать параллельным агентам конфликтовать

Когда над одним workspace работают несколько агентов или человек с агентом, главный риск — не синтаксическая ошибка, а конфликт владения. Один агент делает Academy, другой меняет Scanner, третий проверяет Docker. Если каждый считает весь репозиторий своим, итогом будет случайная смесь unrelated refactor, потерянных изменений и тяжелого review.

В задачах AI Academy Scanner был явно запрещен: `src/features/scanner`, `scripts/scanner-ws-probe.ts`, `docker/scanner-ws-probe-entrypoint.sh`. При этом в рабочем дереве мог быть unrelated diff в Scanner. Правильное поведение агента — заметить его, не трогать и не откатывать. Git status показывает реальность workspace, но не дает права переписывать чужую работу.

Ownership map

Agent A: src/features/ai-academy, src/app/academy
Agent B: src/features/scanner, scripts/scanner-ws-probe.ts
Shared: src/components/ui only after explicit approval
Forbidden for A: Docker, auth, Scanner, persistence infrastructure

Ownership map особенно важен, когда есть shared components. Например, Academy использует `Card`, `Badge`, `Button`, `MetricBlock`. Если для курса нужно улучшить длинный контент, лучше расширить `ContentRenderer` внутри Academy, чем менять глобальный `Card` для всего проекта. Shared UI можно менять только когда это действительно изменение design system, а не удобство одной feature.

• Запрещенные директории перечислены явно.
• Shared files требуют отдельного обоснования.
• Unrelated git diff не откатывается.
• Agent сообщает о чужих изменениях, если они влияют на задачу.
• Каждая migration относится к своему модулю и не чинит соседние таблицы.

Еще один слой защиты — финальный отчет. В нем агент должен явно написать, какие forbidden files не изменялись. Это не формальность. Такая строка помогает reviewer быстро понять, что границы соблюдены, и отделить текущий diff от unrelated изменений в workspace.