Capstone: Triaging a Queue of Ten AI PRs

Сценарий капстоуна: утро понедельника, за выходные агенты закрыли бэклог и в очереди десять PR. Ваш бюджет — девяносто минут на всю очередь. Цель — не отревьюить всё идеально, а принять десять правильных решений о маршрутизации.

Состав очереди (сгенерируйте агентом по этим описаниям в своём учебном репозитории или используйте набор курса):

1. исправление опечаток в README и docstrings — 40 строк;
2. патч-обновление трёх зависимостей от Dependabot — lockfile;
3. новые unit-тесты для существующего модуля утилит — 200 строк, ожидания старых тестов не тронуты;
4. багфикс расчёта скидки с одним тестом — 60 строк;
5. новый CRUD-эндпоинт по образцу соседнего — 350 строк с тестами;
6. рефакторинг «улучшил обработку ошибок» в модуле платежей — 500 строк, попутно изменены два теста;
7. фича с новой зависимостью для парсинга дат — 250 строк плюс пакет в package.json;
8. миграция схемы: новое поле плюс backfill-скрипт — 80 строк;
9. «оптимизация производительности» с переформатированием — 1200 строк в 30 файлах;
10. фикс security-находки из SAST: параметризация трёх запросов — 45 строк.

Перед стартом зафиксируйте таймер и таблицу triage: номер PR, уровень риска, сработавшие красные флаги, решение, минуты. Дисциплина времени — часть упражнения: превышение бюджета на PR — это украденное внимание у остальных девяти.

Первый круг — только классификация, без чтения кода. На каждый PR — максимум пять минут и три вопроса из пройденных уроков. Какой уровень риска по путям файлов (урок 6)? Какие красные флаги в diff --stat и описании (урок 2)? Что говорят машинные гейты и агент-ревью, если они настроены (урок 4)?

По итогам каждый PR получает одно из четырёх решений. Авто-мерж — tier 0/1, зелёные проверки, ни одного флага: решение занимает минуту, код не открывается. Быстрое ревью — до пятнадцати минут по отчёту агента-ревьюера и границам диффа: подходит для PR с понятной структурой и одним вопросом, требующим человека. Глубокое ревью — полный протокол трёх проходов: только для PR, где сочетаются высокий tier и реальная сложность; в бюджете девяноста минут таких помещается два, максимум три. Возврат на перегенерацию — структурные проблемы: смешанные уровни риска, шум форматирования поверх семантики, необоснованная зависимость, изменённые ожидания тестов без объяснения. Возврат — это не поражение ревьюера, а самое дешёвое из решений: минута на формулировку структурного требования против часа на героическую вычитку.

Типичная арифметика бюджета для очереди выше: три авто-мержа по 2 минуты, три быстрых ревью по 12, два глубоких по 20 и два возврата по 3 — итого около часа с четвертью, с запасом на непредвиденное. Если ваш план требует шести глубоких ревью — вернитесь к классификации: вы не доверяете собственным гейтам, и это отдельная проблема, которую нужно чинить не сверхурочным чтением, а улучшением автоматики.

Кандидаты на глубокое ревью в этой очереди — PR 6 (платежи, изменённые тесты) и PR 8 (миграция с backfill). Разберём, как на них работает весь арсенал курса.

PR 6, рефакторинг обработки ошибок в платежах. Уровень tier 3 по зоне. Проход контрактов: какие исключения раньше пробрасывались и кем ловились? Расширенный catch — главный подозреваемый на тихое изменение контракта (урок 1). Изменённые ожидания двух тестов — красный флаг из урока 2: требуйте обоснования «почему старое ожидание было неверным» на каждый. Красно-зелёная проверка из урока 5: откатите реализацию — упадут ли новые ожидания? Если тесты зелёные и без рефакторинга, они подогнаны под новое поведение.

PR 8, миграция с backfill. Авто-мерж запрещён технически (урок 6), нужен владелец зоны. Вопросы глубокого прохода: обратима ли миграция и есть ли план отката? Идемпотентен ли backfill при повторном запуске? Что происходит с записями, созданными между миграцией и backfill? Блокирует ли скрипт таблицу на проде? Агент-ревьюер (урок 4) полезен как генератор этих вопросов, но ответы проверяются по коду и прогоном на копии данных.

Контрольные точки остальных решений: PR 4 — красно-зелёное доказательство в описании; PR 7 — проверка пакета по чек-листу цепочки поставок (урок 3) до любого чтения кода; PR 9 — возврат: переформатирование отдельно, оптимизация отдельно, с бенчмарком; PR 10 — быстрое ревью с проверкой, что параметризация закрыла весь класс, а не три найденных места.

Эталонные решения для очереди (ваши могут отличаться при внятном обосновании — оценивается аргументация, а не совпадение):

• авто-мерж: PR 1 (доки), PR 2 (патчи зависимостей), PR 3 (только новые тесты);
• быстрое ревью: PR 4 (багфикс с красно-зелёным доказательством), PR 5 (CRUD по образцу — с проверкой авторизации из урока 3), PR 10 (security-фикс с поиском класса);
• глубокое ревью: PR 6 (платежи), PR 8 (миграция);
• возврат: PR 7 (зависимость не обоснована — пусть агент покажет решение стандартной библиотекой или обоснует пакет), PR 9 (формат и семантика в одном диффе).

Типовые ошибки капстоуна, снимающие баллы:

• полировка возвращаемого — сорок минут комментариев к PR 9 вместо минутного структурного возврата;
• авто-мерж по инерции — PR 5 похож на tier 1 размером и шаблонностью, но новый эндпоинт — это всегда вопрос «кто может вызвать и чьи данные он отдаёт»;
• доверие зелёному CI на tier 3 — «тесты прошли» не отвечает ни на один вопрос про откат миграции;
• равномерное размазывание бюджета — по девять минут на каждый PR означает, что платежи и миграция получили в два раза меньше внимания, чем нужно, а README — в девять раз больше.

Метрики самопроверки: уложились ли в 90 минут; совпало ли распределение решений с эталоном в 7+ случаях из 10; на каждый возврат сформулировано одно структурное требование; ни один tier 3 не прошёл без вопросов об откате. Если по всем четырём — да, вы готовы держать очередь агентов в реальном проекте.