test-gap-audit

Test Gap Audit — это read-only скилл для поиска отсутствующего, слабого, устаревшего или неправильно ограниченного тестового покрытия. Его задача — показать, какие проверки нужны, но их нет, либо почему существующий тест не доказывает важное поведение. Результат должен быть связан с кодовым путём, риском и текущими соглашениями репозитория, а не с абстрактным процентом покрытия. Если область проверки не задана, скилл рассматривает весь репозиторий. Если пользователь указывает feature, pull request, ветку, маршрут, API, workflow, сервис, пакет, исправление дефекта или другой участок, аудит ограничивается этой областью и непосредственно связанными путями. При неясной формулировке выбирается наименьшая полезная граница и фиксируется допущение; отдельный вопрос задаётся только тогда, когда разные границы приведут к существенно разным планам тестирования. В начале аудит устанавливает контекст проекта: стек, test runner, package scripts, CI-проверки, соглашения об именах файлов, fixtures, mocks, factories, browser-инструменты, API-практики и границы monorepo. Затем он раскладывает проверяемое поведение на основной и ошибочные сценарии, edge cases, границы данных, auth/authorization, миграции, конфигурацию и внешние интеграции. После этого сопоставляются прямые и косвенные тесты, их assertions, fixtures и mocks; отдельно отмечаются тесты, чьи названия или данные больше не соответствуют текущему поведению. Скилл ищет не только полностью нетестируемые маршруты и сервисы. Он проверяет отсутствие критического happy path, негативных и permission-сценариев, валидации, pagination, sorting, filtering, часовых поясов, retry, idempotency, empty states, контрактов API и схем, обратной совместимости миграций, а также регрессионных тестов для уже исправленных ошибок. При этом рекомендация должна быть конкретной: какой уровень проверки нужен — unit, integration, component, browser, contract или end-to-end, — где разместить тест, как его назвать и какие значения утверждать. Медленный E2E не предлагается, если то же поведение надёжно доказывается на более низком уровне. Приоритизация использует четыре уровня. P0 — пробелы, способные привести к потере данных, утечке безопасности или приватности, ошибке платежа, разрушительному действию или production outage без практической страховки. P1 — высокорисковые пользовательские пути, авторизация, критические API-контракты, миграции и фоновые задачи. P2 — заметные риски регрессии в edge cases, обработке ошибок, переходах состояния и интеграциях. P3 — менее рискованные улучшения, устаревшие имена, fixture cleanup и полезная полировка покрытия. Доказательства должны ссылаться на поведение или изменённый код и на существующую либо отсутствующую тестовую область; где возможно, указываются файлы и строки. Для каждого вывода объясняется, что текущие тесты уже подтверждают и чего они не подтверждают. Предположительные пробелы помечаются уровнем уверенности. Отдельно фиксируются проверки, которые были запущены, и то, что не проверялось. По умолчанию аудит остаётся read-only. Он может безопасно выполнить обнаружение тестов, typecheck, lint или быстрый фокусный запуск по локальным правилам, но не должен устанавливать зависимости, поднимать долгоживущие сервисы или запускать дорогой полный suite без явной необходимости. Добавление тестов — отдельный режим: тогда сохраняются местный стиль и структура, приоритет получают самые важные пробелы, избегаются широкие snapshots, а после изменения запускаются новые и ближайшие связанные проверки. Сам скилл не является general bug audit: для общей готовности продукта и security-рисков нужны отдельные специализированные проверки.