Зелёные тесты не отвечают на два разных вопроса: пропустили ли мы опасный путь в коде и работает ли изменение после развёртывания. Cursor добавил для них отдельные инструменты. Разделение полезное: замечание к pull request и сигнал из работающего сервиса требуют разных доказательств и разных решений человека.
Два инструмента 23 сентября
Согласно анонсу от 23 сентября 2026, Rollouts и Security Review доступны на Teams и Enterprise. Rollouts составляет план наблюдения по изменению и проверяет его после развёртывания отдельно для каждого окружения. Security Review анализирует pull request на потенциально эксплуатируемые ошибки; вопросы стиля и общего качества остаются за Bugbot.
Rollouts сообщает один из исходов: состояние подтверждено, обнаружена регрессия или данных недостаточно. Он может подготовить revert PR либо передать проблему агенту согласно настройкам, но на дату анонса самостоятельно не выполняет merge и rollback. Security Review пропускает draft PR; к замечанию прикладывает серьёзность, путь атаки и предлагаемое исправление.
План наблюдения нужно прочитать до релиза
Представим изменение обработки повторного webhook оплаты. Сервис может отвечать HTTP 200 и при этом дважды создавать запись о выполнении. Если смотреть только на долю ошибок и задержку ответа, релиз будет выглядеть здоровым.
В предлагаемом плане я бы выделил бизнес-эффект: число обработанных уникальных событий и число повторных действий для одного идентификатора. Далее — технические сигналы: ошибки обработчика, задержка очереди и рост повторов. У каждой метрики должны быть источник, ожидаемый диапазон и срок наблюдения. Эти критерии задаёт команда; инструмент не получает знание бизнес-смысла автоматически.
Отдельно запишите пробелы. Если нужный идентификатор не попадает в разрешённую телеметрию, нельзя объявить отсутствие дубликатов доказанным. Сначала потребуется добавить подходящее наблюдение без чувствительных данных либо выполнить отдельную проверку. Состояние «недостаточно данных» здесь честнее зелёной галочки.
Замечание по безопасности — начало проверки
Допустим, Security Review указал, что новый маршрут позволяет получить чужой объект по идентификатору. Проверяющий должен воспроизвести путь на тестовых данных: два пользователя, два объекта, запрос от первого к объекту второго. Общей фразы «в контроллере нет проверки» недостаточно: авторизация могла выполняться раньше, в middleware или policy.
Если дефект подтверждён, исправление должно закрывать конкретный путь и иметь регрессионную проверку. После этого повторно проверьте доступ владельца: запретить всем проще, чем правильно сохранить разрешённый сценарий. При ложном срабатывании сохраните объяснение, на какое действующее правило опирается отказ от замечания.
Не превращайте автоматический комментарий в основание для слепого merge. Его ценность — в проверяемой гипотезе с указанием места и последствий, а ответственность за принятие исправления остаётся у команды.
Один сервис для первого запуска
Выберите сервис с понятным выпуском, доступной тестовой средой и рабочими метриками. Подключение наблюдения к системе без телеметрии даст больше вопросов, чем ответов. До включения событий определите владельца сигнала и способ отключить автоматизацию.
- В staging намеренно воспроизведите известную безопасную регрессию.
- Проверьте, что отчёт относится к нужному commit и окружению.
- Убедитесь, что отсутствие сигнала не трактуется как успех.
- Пройдите подготовку отката до решения человека, сохранив проверяемый diff.
После пилота считайте подтверждённые находки и время их разбора. Число комментариев не измеряет безопасность, а количество зелёных отчётов не измеряет надёжность релиза. Полезный результат — дефект, который удалось обнаружить, объяснить и исправить до ущерба пользователю.
