Опасные изменения в код-ревью
Ищет в pull request то, за что потом будет стыдно: утечки, дыры, опасные правки
Тема готова к старту: сузить до MVP и работать
Область и границы
четыре роли · четыре ответаКому больно — и можно ли этого человека спросить?
Разработчик смотрит чужой pull request в конце дня и пропускает то, что заметил бы утром
Почему это не решается одним вызовом модели?
Опасность видна только в контексте: одна и та же строка нормальна в тесте и катастрофична в проде. Часть проверок формальна и должна быть детерминированной, часть требует понимания намерения автора
Где должен появиться результат и что здесь необратимо?
Результат — комментарии в ревью и блокировка слияния: это останавливает чужую работу
Что будет считаться успехом?
Опасное ловится до слияния, а команда не отключает проверку из-за шума
Автор изменения знает о проверке и может подстраиваться: спрятать секрет, разнести опасное по коммитам
Есть публичные наборы или открытые данные; живой контекст добирается разговором
Открытые репозитории с историей уязвимостей и исправлений: реальные опасные изменения там уже размечены датой фикса. Свой проект даёт вторую половину — живые pull request
О чём тема
Ревью смотрят люди, и они устают: секрет в коммите, отключённая проверка прав, запрос к базе без ограничения — всё это проходит на четвёртом часу. Область — поймать опасное изменение в момент ревью и объяснить, чем оно опасно, не завалив команду ложными срабатываниями. Такое решение брало Google Cloud Grand Prize на хакатоне GitLab в 2026-м.
Зачем это людям
Ловить опасные изменения до слияния, не превращая ревью в поток ложных тревог.
Что предстоит выяснить
ответов здесь нетГотового решения в каталоге нет намеренно: тема задаёт область и границы, а что и как строить — работа команды. Это и защищают на приёмке.
Взять эту тему
Тему из каталога берёт любая команда, одобрение не требуется. Одну тему могут взять несколько команд — на Demo Day видно, насколько разошлись решения.