6.5 KiB
| title | description | lang |
|---|---|---|
| Код-ревью – Документация Agent Teams | Проверять diff по задаче, принимать или отклонять hunks, оставлять inline comments и управлять review states от none до approved. | ru-RU |
Код-ревью
Код-ревью в Agent Teams строится вокруг задачи. Вы смотрите изменения конкретной задачи, а не огромный неструктурированный diff.
Поверхность ревью
Для каждой завершённой задачи, затронувшей файлы, review UI позволяет:
- Смотреть changed files с контекстом до/после
- Принимать или отклонять отдельные hunks
- Оставлять inline comments
- Связывать diff с описанием задачи и логами агента
Решения на уровне hunk
Принимайте маленькие правильные изменения и отклоняйте отдельные ошибки без удаления всей работы. Это полезно, когда агент в целом решил задачу, но переборщил в одном файле.
::: tip Принимайте по частям Если 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 |
Инициирование ревью
- Откройте завершённую задачу
- Перейдите на вкладку Changes
- Если diff выглядит разумно, нажмите Request Review, чтобы переместить задачу в колонку review
Во время ревью задача ещё не считается завершённой, поэтому другие teammates или lead могут всё ещё комментировать её.
Review loop
Здоровый review loop выглядит так:
- Owner публикует result comment с changed scope и verification
- Reviewer открывает task diff и сверяет hunks с task description
- Reviewer принимает хорошие hunks, отклоняет плохие или requests changes
- Owner исправляет только requested scope и пишет follow-up comment
- 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.
::: warning Не запускайте автоформатирование по всему проекту
Если задача не специфически про форматирование, избегайте pnpm lint:fix на несвязанных файлах. Это создаёт шум в review surface.
:::