Команда /dr-qa — четыре слоя верификации
Как /dr-qa проверяет соответствие PRD, соответствие дизайну, полноту плана, ожидания оператора и качество кода — по порядку — прежде чем что-либо можно отправить в архив.
Код, который компилируется, — это не то же самое, что код, который работает. Команда /dr-qa — это верификационные ворота между реализацией и архивированием. Она запускает четыре слоя проверок — каждый независимый, каждый со своим вердиктом — и направляет дальше только тогда, когда совокупный результат преодолевает планку.
Команда читает все артефакты, созданные выше по пайплайну: PRD, дизайн-документы, план реализации, ожидания оператора и сам код. Каждый слой — условный: он запускается только при наличии соответствующего артефакта. Задача без PRD пропускает Layer 1; задача без дизайн-документов пропускает Layer 2. Вердикт каждого выполненного слоя участвует в общем результате.
Что она делает
Layer 1 проверяет соответствие PRD. Каждое заявленное требование сравнивается с реализацией. Помечаются отсутствующие функции — то, что есть в PRD, но не построено. Также помечается разрастание области — то, что построено, но не было в PRD. Оба — явные находки, не наблюдения.
Layer 2 проверяет соответствие дизайну. Архитектурные решения, задокументированные в creative-файлах, сравниваются с реальным кодом. Отклонение выявляется и оценивается: это улучшение или регресс? Слой не считает отклонения автоматически ошибкой, но требует их признания, а не невидимости.
Layer 3 проверяет полноту плана. Каждый шаг плана реализации проверяется: выполнен, пропущен или изменён. Пропущенные шаги оцениваются на риск. Незапланированные дополнения перечисляются. Layer 3b, который запускается при наличии файла ожиданий, наиболее непосредственно связан с первоначальным намерением оператора. Каждое пожелание из файла ожиданий оценивается по критерию успеха, определённому при его создании. Вердикт для каждого пожелания записывается обратно в файл ожиданий, и команда запускает скрипт-валидатор для подтверждения совокупного статуса.
Layer 4 проверяет качество кода: запускает тестовый набор, сканирует на уязвимости безопасности, проверяет антипаттерны — например, методы длиннее 50 строк или отсутствующую обработку ошибок в асинхронных операциях — и верифицирует каждый критерий «определения готового». Когда изменённые файлы включают фронтенд-разметку, запускается Playwright-проход для получения скриншота и трейса работающего интерфейса.
Один конкретный пример
Задача реализовать rate-limiting на уровне тенанта поступает в /dr-qa после реализации. Layer 1 обнаруживает, что PRD требовал HTTP 429 с заголовком Retry-After — заголовок отсутствует в реализации. Вердикт Layer 1: FAIL. Поскольку Layer 1 — самый ранний провалившийся слой, общий вердикт BLOCKED, и маршрутизация указывает обратно на /dr-do с фокусом на отсутствующий заголовок. Остальные слои всё равно запускаются и фиксируются, но самый ранний провал определяет целевой маршрут возврата. После исправления и повторного запуска все слои проходят, и задача переходит к /dr-compliance.
Место в пайплайне
Команда запускается после /dr-do для задач уровней 3 и 4. Задачи уровней 1 и 2 могут пропустить её и идти прямо к архивированию. Отчёт QA записывается в datarim/qa/ и хранится как аудиторский след. При повторном запуске после исправления новый отчёт получает версионный суффикс вместо перезаписи предыдущего.
При общем вердикте ALL_PASS или CONDITIONAL_PASS пайплайн направляет к /dr-compliance для финального укрепления перед архивом. При BLOCKED цель маршрутизации — самый ранний провалившийся слой: Layer 1 ведёт обратно к /dr-prd; Layer 2 — к /dr-design; Layer 3 — к /dr-plan; Layers 3b и 4 — обратно к /dr-do. Эта маршрутизация детерминирована, не является суждением.
Общую картину пайплайна даёт пост что такое Datarim; о стадии реализации, которая предшествует верификации, — в описании команды /dr-do.