Чек-лист ожиданий оператора

Выбранные документы задачи

Начиная с 4.3.3 проверки читают поля prd и plan из описания задачи, включая явные версии PRD и плана. Ошибочный выбор вызывает ошибку; чистая старая копия не подменяет выбранный документ. Без указателей сохраняется прежнее поведение с учётом сложности задачи. Поле ожиданий parent_prd должно ссылаться на выбранный PRD. Проверяются идентификаторы и допустимые пути, но не произвольные метаданные документа и не атомарность при параллельном редактировании.

Зачем это нужно

Чек-лист ожиданий — это список того, что оператор хочет проверить после завершения задачи, записанный его собственными словами, без жаргона и сокращений. Чтобы и через неделю можно было открыть файл и сразу понять, чего ждали от задачи. Для больших задач лист заводится на стадии требований, для задач поменьше — на стадии планирования. На стадии проверки каждый пункт получает один из четырёх статусов (выполнено, частично, не выполнено, неприменимо), на стадии закрепления тот же лист перепроверяется ещё раз, а в архивный документ попадает короткий человеческий комментарий по каждому пункту.

Из чего состоит файл

• Frontmatter — идентификатор задачи, тип артефакта, версия схемы (новые файлы пишутся с schema_version: 4; v1–v3 по-прежнему читаются), команда создания, ссылки на родительские файлы (исходное задание, документ требований).
• Каждый пункт — стабильный slug (ASCII для новых пунктов; прежние кириллические ID остаются допустимыми), формулировка обычным языком, критерий успешности, опциональная ссылка на формальный критерий приёмки.
• Журнал статусов — каждая стадия конвейера дописывает свою строку: «время / локальное время · команда · прежний статус → новый статус · причина».
• Текущий статус — одно из значений: ожидается, выполнено, частично, не выполнено, неприменимо, удалено (pending, met, partial, missed, n-a, deleted).
• Привязка к требованию заказчика (схема v4) — каждый пункт объявляет customer_derived: true | false; пункт с true также содержит ID требования, класс поверхности, видимость и ссылку на coverage receipt.
• Строка override (по желанию) — мягкое вето, позволяющее частичному или невыполненному пункту не блокировать переход. С версии 2.31.0 у override есть проверка авторства: override оператора принимается безусловно, а override агента должен указывать разрешённый класс (time-dependent / external-blocker / operator-authorized / plan-scope-boundary) и id артефакта, существующий в бэклоге или индексе задач — агент больше не может «закрыть» пробел одной только прозой.

Совместимость языков

Новые шаблоны сохраняют машинные ключи success_criterion, linked_ac, status_history и current_status. Общий разборщик также принимает существующие английские заголовки, включая Operator expectations и Related AC from PRD, и прежние русские названия. Проверяется каждая ссылка на V-AC; перевод не отменяет требования к доказательствам, статусам и разрешённым исключениям.

Проверка статусов

На стадии проверки появляется отдельный слой, который проходит по каждому пункту, выставляет статус, дописывает одну строку в журнал и обновляет текущее значение. Встроенный валидатор затем решает, проходит ли задача (все выполнены или закрыты override), частично проходит (есть частичные с обоснованием) или останавливается (есть невыполненные без override). При остановке система предлагает оператору вернуть задачу в работу с указанием только тех slug-ов, по которым осталась работа.

Почему именно так

Плоский markdown-формат делает лист читаемым в любом редакторе — оператор может его просмотреть, поправить и прокомментировать без специальных инструментов. Хранение журнала статусов рядом с самим пунктом сохраняет историю проверок: если квалити-проверка проходит дважды (промежуточная и финальная), обе оставляют свои строки.

Источник

Контракт поставляется с Datarim v2.8.0.