Код-ревью

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Верификация

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

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

4.3 KiB Raw Blame History Unescape Escape