Скил health-controller-stub-detector — поймать стабы до блокировки комплаенса

Эндпоинт здоровья, возвращающий HTTP 200 с полем статуса pending-integration, может пройти автоматизированный смок-тест. Тест видит 200, поле присутствует, ни одна проверка не падает. Но поле — заглушка, а не живой пробник: нижестоящий сервис ещё не подключён, и эндпоинт лжёт о состоянии системы. Скил health-controller-stub-detector выявляет этот класс дефектов на этапе реализации — до того, как они доходят до проверки качества.

Скил вызывается на шаге 7 /dr-do, когда задача затрагивает файлы, совпадающие с паттернами *health*controller*, *health*service*, *liveness*, *readiness*, *status*indicator* и аналогичные ролевые имена в любом стеке.

Детектор

Проверка выполняет grep по добавленным строкам диффа — не по всему файлу — в поиске шести литеральных паттернов: pending-integration, not-implemented, not_implemented, unimplemented, "stub", а также любых командных соглашений по именованию заглушек, которые оператор добавляет в набор. Уже существующие стаб-литералы в нетронутых строках генерируют только неблокирующий advisory; блокирующий гейт применяется исключительно к новым добавлениям в текущем диффе.

Три диспозиции для каждого совпадения

Когда детектор находит стаб-литерал в новых добавленных строках, оператор обязан выбрать одну из трёх явных диспозиций до продвижения задачи. Первая — реализовать живой пробник прямо сейчас: заменить литерал реальной проверкой здоровья нижестоящего сервиса и убрать заглушку. Вторая — отложить явно: перенести заглушку в чётко обозначенный раздел отложенных задач контроллера, добавить инлайн-комментарий с номером трекинг-тикета и открыть backlog-элемент по стандартному шаблону именования. Третья — задокументировать пункт как выходящий за рамки задачи и сослаться на идентификатор задачи-продолжения.

Оставить стаб-литерал без одной из трёх зафиксированных диспозиций — недопустимый результат. Именно этот путь ведёт к молчаливому разрыву контракта, который скил был создан закрыть.

Инцидент, ставший основой скила

Многомодальный поток запросов был реализован end-to-end в нижестоящем сервисе. Индикатор этого сервиса в контроллере здоровья вышестоящего сервиса остался хардкодным литералом pending-integration — отложенная интеграция health-reporter, не входившая в текущую задачу. Критерий приёмки, проверявший эндпоинт /health, принял литерал за доказательство подключения. Проверка прошла. Разрыв контракта всплыл только на гейте комплаенса — поздно в пайплайне — и заблокировал цикл вынесения вердикта до тех пор, пока оператор не согласовал формулировку.

Поймать паттерн на этапе /dr-do, а не /dr-compliance, исключает дополнительный цикл пайплайна, которого требует такое согласование.

Связь с ожиданиями

Скил перекрёстно ссылается на контракт expectations-checklist: пожелания не должны цитировать литерал из /health как доказательство подключения сервиса. Эндпоинт здоровья, возвращающий стаб-статус, — свидетельство отсрочки, а не интеграции. Когда пожелание написано так, чтобы считать этот эндпоинт авторитетным, детектор стабов и валидатор ожиданий выдадут противоречивые вердикты: стаб говорит «не подключено», пожелание говорит «проверь эндпоинт». Исправление — привести критерий пожелания в соответствие с реальным состоянием реализации.

Подробнее о пайплайне Datarim — в посте что такое Datarim, а о том, что считается проверенными доказательствами на этапе QA, — в посте о скиле expectations-checklist.