Чек-лист ожиданий оператора
Список «что проверить после работы» в человеческой формулировке — стабильный slug, журнал статусов, текущий статус, мягкий override оператора. Заводится на требованиях, перепроверяется при качестве и закреплении.
Зачем это нужно
Чек-лист ожиданий — это список того, что оператор хочет проверить после завершения задачи, записанный его собственными словами, без жаргона и сокращений. Чтобы и через неделю можно было открыть файл и сразу понять, чего ждали от задачи. Для больших задач лист заводится на стадии требований, для задач поменьше — на стадии планирования. На стадии проверки каждый пункт получает один из четырёх статусов (выполнено, частично, не выполнено, неприменимо), на стадии закрепления тот же лист перепроверяется ещё раз, а в архивный документ попадает короткий человеческий комментарий по каждому пункту.
Из чего состоит файл
- Frontmatter — идентификатор задачи, тип артефакта, команда создания, ссылки на родительские файлы (исходное задание, документ требований).
- Каждый пункт — стабильный slug (кебаб-кейс, разрешена кириллица), формулировка обычным языком, критерий успешности, опциональная ссылка на формальный критерий приёмки.
- Журнал статусов — каждая стадия конвейера дописывает свою строку: «время / локальное время · команда · прежний статус → новый статус · причина».
- Текущий статус — одно из значений: ожидается, выполнено, частично, не выполнено, неприменимо.
- Строка override (по желанию) — мягкое вето оператора с обоснованием от 10 символов; позволяет частичному или невыполненному пункту не блокировать переход.
Проверка статусов
На стадии проверки появляется отдельный слой, который проходит по каждому пункту, выставляет статус, дописывает одну строку в журнал и обновляет текущее значение. Встроенный валидатор затем решает, проходит ли задача (все выполнены или закрыты override), частично проходит (есть частичные с обоснованием) или останавливается (есть невыполненные без override). При остановке система паразрозано предлагает оператору вернуть задачу в работу с указанием только тех slug-ов, по которым осталась работа.
Почему именно так
Плоский markdown-формат делает лист читаемым в любом редакторе — оператор может его просмотреть, поправить и прокомментировать без специальных инструментов. Хранение журнала статусов рядом с самим пунктом сохраняет историю проверок: если квалити-проверка проходит дважды (промежуточная и финальная), обе оставляют свои строки.
Источник
Контракт поставляется с Datarim v2.8.0.