pr-review-discipline

name	pr-review-discipline
description	Ревью PR/MR: чек-лист (хирургичность, тесты, async, безопасность, доки), исходы approve/reject, запрет апрува при красном CI.

Skill: pr-review-discipline

Правила ревью pull request / merge request. Дополняет промпт .agents/prompts/code-review.prompt.md (чек-лист проверок) и добавляет процедуру исхода ревью.

Когда использовать

• Ревьюишь PR/MR (свой или чужой).
• Пользователь попросил проверить ветку перед merge.
• Проводишь само-ревью перед открытием PR.

Алгоритм

1. Проверить CI зелёный. Если pytest/flake8/check_env_sync/check_sprint_sync/check_doc_links красные — reject без детального ревью. Сначала чиним CI.
2. Пройти чек-лист из .agents/prompts/code-review.prompt.md:
   • Хирургичность — каждая изменённая строка соответствует задаче (AGENTS.md §3).
   • Минимализм — нет лишних абстракций/фич (AGENTS.md §2).
   • Тесты на новое поведение — изменения в app/ сопровождаются тестом; моки внешних систем, без сети (_docs/instructions.md §8.1).
   • Покрытие — порог --cov-fail-under=80 не нарушен.
   • Async-дисциплина — I/O через await, синхронные либы через asyncio.to_thread (_docs/instructions.md §4).
   • Обработка ошибок — ожидаемые исключения ловятся, пользователю — человеческое сообщение, stacktrace — в logger.exception (_docs/instructions.md §5).
   • Безопасность — нет хардкоженных секретов; конфиг через Settings; sanitize на входе / bastion на выходе; per-user скоуп read_file (_docs/security.md).
   • Документация — изменение поведения отражено в _docs/; ссылки относительные (_docs/instructions.md §9).
   • Язык — комментарии/докстринги/логи/сообщения — на русском; идентификаторы — латиницей (_docs/instructions.md §1).
3. Замечания — сгруппировать по серьёзности: blocker → major → minor → nit. Для каждого: файл, строка, проблема, конкретное предложение.
4. Исход ревью:
   • Approve — нет blocker/major, nit можно не блокировать.
   • Approve with comments — есть minor, не блокирующие merge, но желательно поправить.
   • Request changes — есть blocker или major.
5. Не апрувить если:
   • CI красный.
   • Нет тестов на новое поведение в app/.
   • Документация не обновлена при изменении поведения.
   • Найден хардкоженный секрет/токен.

Чего избегать

• Апрува при красном CI — сначала зелёный, потом ревью.
• Апрува без проверки тестов — «работает» ≠ «проверено».
• Попутных замечаний на код вне diff'а (см. AGENTS.md §3 — хирургичность работает в обе стороны).
• Несуществующих функций/параметров в замечаниях — проверяй по коду, не додумывай.