Скил v-ac-axis-split — детерминированные и статистические проверки должны быть разделены
Как скил v-ac-axis-split находит V-AC-группы, смешивающие правила и пороговые метрики, и почему объединение двух осей в одну группу создаёт ложную уверенность.
Проверка проходит либо по правилу, либо по наблюдению. «Статус-код равен 200» имеет единственно верный ответ для любого ответа сервера. «Частота ошибок ниже 1% за час» зависит от окна измерения, объёма выборки и порогового значения. Скил v-ac-axis-split применяет простое ограничение: два вида проверок не должны жить в одной V-AC-группе.
Скил загружается на этапах /dr-prd и /dr-plan, до начала реализации. Задача — пометить смешанные V-AC-группы и потребовать разделения до финализации спецификации.
Почему смешение осей создаёт проблемы
Детерминированные и статистические проверки опираются на разные цепочки доказательств. Детерминированная проверка — «схема соответствует XSD», «поле присутствует», «код возврата равен нулю» — либо выполнена, либо нет, без серой зоны. Статистическая проверка — «p99-задержка ниже 500 мс», «частота ошибок ниже 1% за час» — проходит только при определённых условиях измерения, и провал может означать как сломанную систему, так и слишком короткое окно наблюдения.
Когда обе оси находятся в одной группе, ретроспектива на одном из пайплайнов Datarim показала следующее: детерминированные проверки всегда проходили, статистические были реальным источником неопределённости, — но из-за объединения в группу провал изначально классифицировали как нестабильный тест, а не как ошибку проектирования. Различие стало видимым только после разделения осей.
Паттерн разделения
Процедура состоит из четырёх шагов. Сначала каждая V-AC-запись классифицируется как детерминированная (однозначное правило) или статистическая (порог за окно). Затем, если в одной группе есть оба типа, они разделяются на две: V-AC-N для детерминированных и V-AC-M для статистических. Статистическая группа должна явно указывать окно измерения, объём выборки и доверительный интервал. Детерминированная группа должна быть привязана к bats-тесту, spec-утверждению или grep-доказательству — монотонной проверке, дающей одинаковый результат при каждом запуске.
Расширение для активации гейта
Скил включает второй паттерн для связанной проблемы: задачи, которые выпускают новый гейт-валидатор или переводят существующий из advisory-режима в fail-hard. В этом случае Phase 4 /dr-plan должна содержать dry-run-строку со списком всех файлов, которые сейчас не проходят под scope гейта. Любой файл, объявленный в PRD вне scope, но попадающий под вызов гейта, должен быть либо переписан в той же задаче, либо явно исключён с документированным сужением scope. Задача активации гейта, которая откладывает файлы внутри своего же scope, блокирует сама себя: гейт запустится против этих файлов во время архивирования и отклонит архив, который его же активировал.
Общая картина — в посте что такое Datarim. Смежный материал о требованиях к доказательствам — в посте о скиле verification-before-completion.