Код-ревью

Код-ревью в Agent Teams строится вокруг задачи. Вы смотрите изменения конкретной задачи, а не огромный неструктурированный diff.

Поверхность ревью

Для каждой завершённой задачи, затронувшей файлы, review UI позволяет:

• Смотреть changed files с контекстом до/после
• Принимать или отклонять отдельные hunks
• Оставлять inline comments
• Связывать diff с описанием задачи и логами агента

Решения на уровне hunk

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

Принимайте по частям

Если diff в основном верен, сначала примите хорошие hunks и запросите правки только для проблемных частей. Это не даёт доске застопориться.

Используйте hunk-level decisions так:

Situation	Action
Correct scoped change	Accept hunk
Correct idea, wrong file или broad refactor	Reject hunk и request narrower fix
Unclear behavior change	Comment и попросить verification
Generated formatting noise	Reject, если formatting не был частью task

Инициирование ревью

1. Откройте завершённую задачу
2. Перейдите на вкладку Changes
3. Если diff выглядит разумно, нажмите Request Review, чтобы переместить задачу в колонку review

Во время ревью задача ещё не считается завершённой, поэтому другие teammates или lead могут всё ещё комментировать её.

Review loop

Здоровый review loop выглядит так:

1. Owner публикует result comment с changed scope и verification
2. Reviewer открывает task diff и сверяет hunks с task description
3. Reviewer принимает хорошие hunks, отклоняет плохие или requests changes
4. Owner исправляет только requested scope и пишет follow-up comment
5. Reviewer approves, когда task result и diff совпадают

Пример request-changes comment:

Please keep the copy improvements, but revert the unrelated runtime wording in the provider table. Add the `pnpm --dir landing docs:build` result before resubmitting.

Состояния ревью

Состояние	Значение
none	Задача новая, в работе или завершена, но ещё не на ревью
review	Задача активно на ревью
needsFix	Запрошены правки; владелец должен обновить до повторного approve
approved	Ревью принято, задача финализирована

Рабочий процесс ревью агентами

Команды могут ревьюить работу друг друга до вашего финального решения. Это ловит очевидные регрессии, но risky areas всё равно стоит проверять вручную.

Agent review полезнее, когда reviewer получает ясный rubric. Например, попросите проверить только docs clarity, только IPC safety или только test coverage. Широкие запросы "review everything" обычно дают более слабый feedback.

Участники ревью

Team lead — ревьюер по умолчанию. Вы можете настроить дополнительных ревьюеров в настройках Kanban, если хотите, чтобы peers ревьюили работу друг друга.

Что проверять вручную

Приоритетные области при ревью:

• Provider auth и runtime detection — не сломает ли агент настройку runtime для других путей?
• IPC, preload и filesystem boundaries — сохраняйте разделение ответственности Electron
• Git и worktree behavior — проверяйте имена веток, коммиты и push
• Parsing и task lifecycle logic — изменения в task references, chunking или filtering могут сломать доставку сообщений
• Persistence и code review flows — изменения в хранении задач или review state должны оставаться консистентными через IPC layers

Canonical feature layout и hard guardrail links смотрите в Архитектуре для контрибьюторов.

Верификация

Лучше запускать focused verification commands. Broad formatting или lint-fix команды не стоит использовать, если задача явно не про форматирование.

Хорошие verification comments включают command и result:

Verified with `pnpm --dir landing docs:build`. Build passed.

Если verification пропущена, task comment должен объяснять почему:

Docs-only wording change. Build not run because the existing dev server was busy; checked Markdown links manually.

Не запускайте автоформатирование по всему проекту

Если задача не специфически про форматирование, избегайте pnpm lint:fix на несвязанных файлах. Это создаёт шум в review surface.