# Совместная разработка
Версия источника: 4880e8b4372c96001c2e052be28b68a95d31252b
Синхронизировано: 2026-11-09T11:15:07.649Z
Источник: https://github.com/sergey-from-riders/vibecoding-base/tree/4880e8b4372c96001c2e052be28b68a95d31252b
## Оглавление
- [Pull request](#collaboration-small-pr)
- [Распределение изменений](#collaboration-ownership)
- [Рабочее дерево Git](#collaboration-preserve-changes)
- [Code review](#collaboration-review)
- [Передача результата](#collaboration-handoff)
- [Architecture Decision Record](#collaboration-decisions)
# Pull request
## Коротко
Ревьюеру проще проверить изменение с одной целью и воспроизводимой проверкой.
## Плохо
```text
В одном PR: редизайн, платежи и обновление БД.
```
## Хорошо
```text
PR: исправление двойной оплаты.
Описание причины и тест повторного запроса.
```
## Почему
Разнородные изменения скрывают ошибки и затрудняют откат.
## Когда применять
Размер определяется связностью задачи, а не жёстким лимитом строк.
## Как проверить
- Можно ли объяснить назначение PR одним предложением?
## Человек
Определяет самостоятельный результат, который можно проверить и выпустить.
## Агент
Проверяет рабочее дерево, сохраняет чужие изменения и передаёт diff, команды проверки и ограничения.
Контроль результата:
- Можно ли объяснить назначение PR одним предложением?
## Источники
- [Small CLs](https://google.github.io/eng-practices/review/developer/small-cls.html)
Уровень: Рекомендуется. Проверено: 2026-11-09. Изменено: 2026-11-09.
[Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/4880e8b4372c96001c2e052be28b68a95d31252b/registry/standards/collaboration/team/rules/small-pr.md)
---
# Распределение изменений
## Коротко
Договоритесь, кто меняет общий контракт и какие файлы затрагивает каждый участник.
## Плохо
```text
Два агента одновременно переписывают один модуль.
```
## Хорошо
```text
Один меняет контракт.
Другой работает в согласованном компоненте.
Совместная проверка после объединения.
```
## Почему
Отдельные рабочие каталоги не устраняют смысловые конфликты.
## Когда применять
Это инженерное правило справочника, а не требование протокола. Первоисточник описывает подход или механизм; конкретный процесс выбирается проектом.
Для людей и агентов. Небольшую последовательную задачу не нужно искусственно распараллеливать.
## Как проверить
- У общих файлов есть ответственный?
## Человек
Назначает владельцев компонентов и порядок объединения параллельных изменений.
## Агент
Проверяет рабочее дерево, сохраняет чужие изменения и передаёт diff, команды проверки и ограничения.
Контроль результата:
- У общих файлов есть ответственный?
## Источники
- [About code owners - GitHub Docs](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners)
- [Git - git-worktree Documentation](https://git-scm.com/docs/git-worktree)
Уровень: Рекомендуется. Проверено: 2026-11-09. Изменено: 2026-11-09.
[Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/4880e8b4372c96001c2e052be28b68a95d31252b/registry/standards/collaboration/team/rules/ownership.md)
---
# Рабочее дерево Git
## Коротко
Перед началом проверьте рабочее дерево и отделите собственные изменения.
## Плохо
```text
Неизвестный файл мешает → git reset --hard.
```
## Хорошо
```text
Проверка diff.
Свои изменения в отдельной ветке.
Чужая работа сохранена.
```
## Почему
Массовый сброс может уничтожить результат другого участника.
## Когда применять
Особенно важно в общей папке; удаление требует понимания происхождения изменений.
## Как проверить
- Сравните состояние до и после задачи.
## Человек
Уточняет принадлежность незавершённых изменений, если это нельзя установить по истории.
## Агент
Проверяет рабочее дерево, сохраняет чужие изменения и передаёт diff, команды проверки и ограничения.
Контроль результата:
- Сравните состояние до и после задачи.
## Источники
- [Git - git-status Documentation](https://git-scm.com/docs/git-status)
- [Git - git-reset Documentation](https://git-scm.com/docs/git-reset)
Уровень: Обязательно. Проверено: 2026-11-09. Изменено: 2026-11-09.
[Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/4880e8b4372c96001c2e052be28b68a95d31252b/registry/standards/collaboration/team/rules/preserve-changes.md)
---
# Code review
## Коротко
Ревью должно находить нарушения требований, а не только обсуждать стиль.
## Плохо
```text
Выглядит красиво, принимаем.
```
## Хорошо
```text
Проверены права, ошибки и совместимость.
Тест воспроизводит исходную проблему.
```
## Почему
Успешная сборка не доказывает правильность бизнес-правил.
## Когда применять
Глубина ревью зависит от риска; форматирование лучше поручить инструментам.
## Как проверить
- Проверен хотя бы один отрицательный сценарий?
## Человек
Принимает бизнес-поведение, риски и существенные архитектурные решения.
## Агент
Проверяет рабочее дерево, сохраняет чужие изменения и передаёт diff, команды проверки и ограничения.
Контроль результата:
- Проверен хотя бы один отрицательный сценарий?
## Источники
- [What to look for in a code review](https://google.github.io/eng-practices/review/reviewer/looking-for.html)
Уровень: Рекомендуется. Проверено: 2026-11-09. Изменено: 2026-11-09.
[Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/4880e8b4372c96001c2e052be28b68a95d31252b/registry/standards/collaboration/team/rules/review.md)
---
# Передача результата
## Коротко
В конце задачи укажите, что изменилось, как проверено и что осталось неизвестным.
## Плохо
```text
Готово, продолжай сам.
```
## Хорошо
```text
Изменено: обработка повторов.
Проверено: двойной запрос.
Не проверено: живой провайдер.
```
## Почему
Следующий участник не должен восстанавливать весь разговор.
## Когда применять
Это инженерное правило справочника, а не требование протокола. Первоисточник описывает подход или механизм; конкретный процесс выбирается проектом.
Для передачи между людьми, агентами и сменами поддержки.
## Как проверить
- Можно ли продолжить по ссылке на PR и короткой заметке?
## Человек
Назначает принимающего и критерии завершения работы.
## Агент
Проверяет рабочее дерево, сохраняет чужие изменения и передаёт diff, команды проверки и ограничения.
Контроль результата:
- Можно ли продолжить по ссылке на PR и короткой заметке?
## Источники
- [Writing good CL descriptions](https://google.github.io/eng-practices/review/developer/cl-descriptions.html)
Уровень: Рекомендуется. Проверено: 2026-11-09. Изменено: 2026-11-09.
[Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/4880e8b4372c96001c2e052be28b68a95d31252b/registry/standards/collaboration/team/rules/handoff.md)
---
# Architecture Decision Record
## Коротко
Сохраните причину выбора, альтернативы и последствия там, где их найдёт команда.
## Плохо
```text
Почему здесь очередь? Никто не помнит.
```
## Хорошо
```text
Решение: очередь для медленной отправки.
Цена: повторная обработка и мониторинг.
```
## Почему
Знание причины помогает отличить нужное ограничение от исторической случайности.
## Когда применять
Для архитектуры и необратимых решений; мелкой правке отдельный ADR не нужен.
## Как проверить
- У решения есть причина и условие пересмотра?
## Человек
Фиксирует принятое решение, ограничения и отвергнутые альтернативы.
## Агент
Проверяет рабочее дерево, сохраняет чужие изменения и передаёт diff, команды проверки и ограничения.
Контроль результата:
- У решения есть причина и условие пересмотра?
## Источники
- [Documenting Architecture Decisions](https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions.html)
Уровень: Зависит от задачи. Проверено: 2026-11-09. Изменено: 2026-11-09.
[Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/4880e8b4372c96001c2e052be28b68a95d31252b/registry/standards/collaboration/team/rules/decisions.md)