Скил expectations-checklist — фиксация приёмочного теста оператора
Как Datarim сохраняет исходный замысел оператора на протяжении всего пайплайна — от PRD до QA и комплаенса — через структурированный файл ожиданий, который блокирует пайплайн при невыполненных пунктах.
Проверка качества агентом надёжна ровно настолько, насколько надёжна цель, по которой проверка происходит. Если цель — парафраз замысла оператора, полученный при генерации критериев приёмки из PRD, проверка может незаметно разойтись с тем, чего человек хотел на самом деле. Скил expectations-checklist сохраняет исходный замысел как отдельный артефакт, принадлежащий оператору.
Файл живёт по пути datarim/tasks/{TASK-ID}-expectations.md. Он создаётся один раз — из PRD или плана — и в дальнейшем только дополняется, но никогда не переписывается. Каждый пункт — одно человекочитаемое пожелание с конкретным критерием успеха, который можно проверить командой или наблюдаемым результатом.
Когда создаётся файл
Для задач уровня L3 и L4 файл создаёт архитектор в ходе /dr-prd — после финализации критериев приёмки. Для задач уровня L2 без PRD его создаёт планировщик в ходе /dr-plan. Для задач L1 файл не обязателен, но его можно добавить по желанию.
Три артефакта образуют триаду: init-task хранит дословный промпт оператора, task-description — интерпретацию агента и заметки по реализации, файл ожиданий — приёмочный тест. У каждого своя роль, каждый создаётся своей стороной.
Схема и типы доказательств
Каждый пункт пожеланий объявляет evidence_type: empirical (команда с реальным stdout), static (grep или проверка файла в дереве исходников) или measurement (числовое значение в сравнении с бюджетом — задержка, покрытие). Поле обязательно в схеме версии 2 и указывает /dr-qa, какие именно доказательства требуются для каждого пожелания.
Переходы статусов — фиксированное перечисление: pending, met, partial, missed, n-a, deleted. История только пополняется: каждое изменение статуса получает строку с датой, а не перезапись.
Блокирующий гейт
На этапах /dr-qa и /dr-compliance валидатор проверяет файл и выносит один из трёх вердиктов. PASS — все пожелания выполнены, неприменимы, ожидают или удалены. CONDITIONAL_PASS — часть пожеланий partial или missed, но у каждого есть написанный оператором override длиной не менее десяти символов. Вердикт BLOCKED останавливает пайплайн, печатает идентификаторы проблемных пожеланий и выдаёт CTA, направляющий работу обратно в /dr-do с этими wish_id в фокусе.
Именно это поведение маршрутизации отличает файл ожиданий от обычных критериев приёмки: невыполненное пожелание не просто попадает в отчёт — оно останавливает пайплайн и точно называет, что нужно исправить.
Дополнение и многофазные задачи
При пересмотре PRD или расширении скоупа новые пожелания добавляются в конец. Существующие пожелания не редактируются; изменение контекста фиксируется строкой в истории. В многофазных задачах-зонтиках пожелания, относящиеся к поздним фазам, остаются pending в ранних фазах — не n-a, что означало бы окончательное исключение из рассмотрения. Строка истории называет фазу, чтобы более поздний аудитор мог отличить «ещё не проверено» от «упущено».
Подробнее о пайплайне Datarim — в посте что такое Datarim, а о том, что происходит после выполнения ожиданий, — в посте о скиле finishing-a-development-branch.