Команда /dr-compliance — адаптивное ужесточение после QA
Как /dr-compliance определяет тип задачи, применяет подходящий контрольный список и выносит вердикт соответствия — финальный гейт перед архивированием.
Пройти QA — не то же самое, что быть готовым к архивированию. У задачи могут быть чистые тесты и корректная логика, но оставаться пробелы в документации, отсутствующие перекрёстные ссылки или конфигурация безопасности, которую так и не проверили. /dr-compliance закрывает этот пробел: это финальный гейт качества между реализацией и постоянной записью.
Ключевое дизайнерское решение — адаптивность. Команда не запускает единый универсальный чеклист на каждой задаче. Она читает задачу, определяет, какая работа была выполнена — код, документация, исследование, юридический контент, контент-материал, инфраструктура или смесь — и применяет только тот чеклист, который соответствует типу.
Семь типов чеклистов
Каждый тип задачи получает свой путь верификации. Для кода запускается 7-шаговый программный чеклист: линтинг, тесты, покрытие, CI/CD-интеграция. Для документации проверяется полнота, точность, согласованность, перекрёстные ссылки и целевая аудитория. Для контента вызываются проходы factcheck и humanize плюс редакционные стандарты. Для инфраструктуры — правильность конфигурации, план отката, мониторинг и безопасность. Смешанные задачи объединяют соответствующие разделы каждого подходящего типа.
Тип определяется через чтение tasks.md, activeContext.md и init-task файла задачи — дословного брифа оператора, записанного при старте задачи. Любое расхождение между изначальным намерением и выполненным результатом должно быть явно отражено в отчёте о соответствии.
Проверка ожиданий
Если у задачи есть файл ожиданий — чеклист критериев успеха, зафиксированных в начале работы — /dr-compliance повторно оценивает каждый элемент и добавляет строку перехода статуса в его историю. Затем запускается shell-валидатор, возвращающий один из трёх результатов: PASS (продолжить), CONDITIONAL_PASS (продолжить с пометкой) или BLOCKED (задачу нельзя архивировать, пока не устранены указанные элементы).
Результат BLOCKED направляет задачу обратно в /dr-do с указанием конкретных проблемных элементов — не расплывчатое «почини и попробуй снова», а точный список того, что реализация должна удовлетворить.
Три вердикта
Команда выносит один из трёх вердиктов: COMPLIANT (все проверки пройдены), COMPLIANT_WITH_NOTES (проходит с незначительными замечаниями, не блокирующими архивирование), или NON-COMPLIANT (найдены критические проблемы). Вердикт NON-COMPLIANT направляет задачу обратно на наиболее раннюю стадию пайплайна, способную устранить сбой — PRD, план или реализацию — а не всегда в реализацию.
Отчёт о соответствии
Результатом является структурированный отчёт, записываемый в datarim/reports/compliance-report-{task_id}.md. Он содержит четыре прозаических раздела — начальная задача, как решили, проверенные артефакты, следующие шаги — и дополнение аудита с пошаговой таблицей вердиктов и оставшихся рисков. Прозаические разделы написаны простым языком для оператора, читающего отчёт без окружающего технического контекста.
Общая картина пайплайна — в посте что такое Datarim. О том, как верификация артефактов работает раньше в пайплайне, рассказывает пост о команде /dr-verify.