Ревью в команде

После второй задачи ALGI получился небольшой diff и пять зелёных тестов. Можно начинать ревью. Откройте рядом задачу, спецификацию и разницу между algi-pain-diary/algi/domain.py и algi-clinician-summary/algi/domain.py в fixtures.

В изменении есть не только новая clinician_report. Добавилась функция удаления контактов, а validate_pain_entry теперь вызывает её при приёме заметки. Это хорошая точка для обсуждения: задача про отчёт затронула данные, которые сохраняются в дневнике.

Что приложить к PR

Начните описание с пользовательского изменения, затем укажите проверенные свойства и оставшиеся вопросы. Для этого примера черновик может выглядеть так:

Добавлен clinician_report: псевдоним пациента, число записей,
средний и максимальный балл, сравнение первого и последнего балла.

Задача: algi-02-clinician-report.
Спецификация: specs/pain-diary.bdd.md.

Также изменён validate_pain_entry: email и телефон удаляются
из заметки при вводе. Нужно согласовать, допустимо ли менять
исходную запись ради защиты отчёта.

Проверки: после прохождения локальной цепочки выполняются
пять тестов. К своему PR приложить журнал конкретного запуска.

Осталось проверить:
- правило вычисления trend отсутствует в спецификации;
- удаление полных имён не реализовано;
- создание PainEntry напрямую обходит очистку в валидаторе.

Требуется ревью владельца доменной логики и правил работы с данными.

Здесь нет утверждения «приватность обеспечена», которое тесты не подтверждают. Ревьюер сразу видит места, где нужно принять решение. Для своего PR замените ожидаемое число тестов фактическим результатом, укажите версию кода и путь к журналу.

В каком порядке смотреть изменение

Сначала сравните поведение с задачей. Разрешалось ли менять валидацию? Как определён trend? Затем посмотрите тесты и входные данные в них. Только после этого переходите к реализации и её качеству: обработке пустого списка, типам, повторному использованию функций.

Проверьте также, не удалены ли старые тесты и не ослаблены ли ожидания ради зелёного результата. Если агент изменил реализацию после последней проверки, результаты тестов уже относятся к другой версии файлов.

Замечание на ревью должно вести к конкретному действию. Например: «Согласовать место очистки заметок в спецификации, затем добавить проверку сохранности исходной записи». Просьба «улучшить безопасность» снова оставит исполнителю неясную задачу.

Когда ревью можно упростить

Для заранее определённых изменений, например исправления ссылки в документации, команда может разрешить принятие после обязательных автоматических проверок. Такое условное одобрение часто называют conditional LGTM.

Условия должны относиться к конкретному diff или строго ограниченному классу изменений. Если после одобрения изменился объём задачи, потребовались новые права или появился риск для данных, решение нужно пересмотреть. Маленький diff в проверке доступа может требовать больше внимания, чем большой diff в документации.

Для отчёта ALGI автоматических тестов пока недостаточно, чтобы снять ручное ревью. Вопросы о данных и составе отчёта остаются открытыми независимо от числа строк.

Как подключать автоматического ревьюера

Сначала дайте ему узкую задачу: найти изменения за пределами задачи, проверить соответствие сценариев тестам или выполнить дополнительный набор проверок. Замечания должны содержать путь, условие ошибки и способ её воспроизвести.

Сравните такие замечания с обычным ревью команды. Сколько оказалось полезными, сколько ошибочными, сколько времени ушло на разбор? Если бот создаёт больше работы, чем снимает, сужайте его задачу или меняйте критерии. Количество комментариев не является мерой качества ревью.

Ограничьте незавершённую работу

Если агентские PR появляются быстрее, чем их принимают, ограничьте число одновременно открытых задач. Назначьте владельца ревью до запуска и договоритесь, кто разбирает blocked. Иначе очередь готовых diff будет расти, а контекст успеет устареть до приёмки.

Для практики заполните описание рисков PR по фактическому diff ALGI. Попросите коллегу назвать одно принятое свойство и один нерешённый вопрос, не открывая переписку. Затем превратите решение по этому вопросу в задачу или запись памяти проекта.