Команда /dr-verify — трёхуровневая верификация артефактов
Как /dr-verify запускает три независимых уровня верификации — детерминированный shell-чек, cross-model peer review и параллельные субагенты — чтобы выявить проблемы до compliance.
PRD, который выглядит полным, может содержать критерии приёмки, которые нельзя проверить. Детальный план может иметь шаги, не покрывающие ни один критерий приёмки. Отчёт о реализации может заявлять полноту, оставляя один AC-пункт без внимания. /dr-verify проверяет всё это, не изменяя ни одного файла.
Это автономная команда верификации в Datarim — вызываемая в любой точке пайплайна, только для поиска проблем. Ничего не исправляется автоматически. Всё помечается для сортировки оператором.
Три уровня, самый быстрый первым
Архитектура работает от дешёвого к дорогому. Уровень 1 — детерминированный shell-пайплайн: dr-verify-floor.sh запускается без участия LLM, производя структурированные JSONL-находки при почти нулевых затратах. Если передан флаг --floor-only, команда останавливается здесь — полезно для быстрых pre-merge проверок.
Уровень 2 — cross-model peer review. Цепочка разрешения провайдера выбирает наиболее дешёвую доступную внешнюю модель — по умолчанию разрешается в DeepSeek через абстракцию coworker, что стоит примерно в 14 раз меньше, чем запуск Sonnet. Рецензент читает артефакты и возвращает структурированные находки с тегами провайдера и шага цепочки разрешения.
Уровень 3 запускает три параллельных субагента на Claude runtime: рецензент, тестировщик и специалист по безопасности. Каждый получает самодостаточный пакет контекста и возвращает находки с тегом своей роли. Все три работают одновременно, а не последовательно.
Что верифицируется
Флаг --stage управляет областью. Стадия prd проверяет PRD и описание задачи на полноту покрытия AC и проверяемость. Стадия plan проверяет, что каждый AC соответствует хотя бы одному шагу плана и что путь отката явно указан. Стадия do проверяет QA-отчёт на непокрытые AC-элементы. Стадия all запускает всё перечисленное плюс cross-artifact drift check, ищущий scope creep, spec decay, execution skew и осиротевшие требования.
Три вердикта и их маршруты
Находки дедуплицируются по всем трём уровням с использованием кортежа из ссылки на артефакт, критерия AC и категории — побеждает первый источник. Затем применяется логика вердикта: PASS означает только находки низкой серьёзности или их отсутствие; CONDITIONAL — хотя бы одна находка средней серьёзности при отсутствии высокой; BLOCKED — хотя бы одна неотброшенная находка высокой серьёзности.
BLOCKED маршрутизирует по категории наиболее серьёзной находки. Находка безопасности направляет на /dr-design — бреши в безопасности требуют редизайна. Находка корректности направляет на /dr-do. Находка полноты направляет на /dr-plan или /dr-prd. Маршрут целится в наиболее раннюю стадию пайплайна, способную реально решить проблему.
Лог аудита
Каждый запуск производит append-only лог аудита по пути datarim/qa/verify-{task-id}-{stage}-{iter}.md. После записи файл получает chmod a-w — он не может быть изменён постфактум. Повторные запуски после исправлений получают суффикс -v2, -v3. Предыдущие логи сохраняются для цепочки аудита.
Общая картина пайплайна — в посте что такое Datarim. О том, что происходит после прохождения верификации, рассказывает пост о команде /dr-compliance.