Отчёт агента о завершении задачи не показывает сам по себе, воспроизводит ли программа нужное поведение. RefTrail предлагает заранее зафиксировать требования и связать каждое с проверяемым результатом. В примере проекта с GNU uniq README сообщает о совпадениях на конкретных наборах и системах; это свидетельство по перечисленным случаям, а не доказательство эквивалентности всей программы.
Зачем принимать работу по критериям
Приёмка должна отвечать на два вопроса: какое требование проверяли и какое наблюдение служит свидетельством результата. Проверка сборки или сообщение агента о завершении не отвечают на них автоматически. Заранее сформулированные критерии позволяют сопоставить ожидаемое поведение с результатом, не подменяя проверку уверенностью исполнителя.
README RefTrail описывает последовательность так: для каждого требования задаются источник и измеримый результат, критерии фиксируются до первой строки продуктового кода, а итоговый отчёт указывает, что подтверждено, какой проверкой и что остаётся открытым. Это описание проекта, а не независимая оценка эффективности метода.
Каталог покрытия и фиксация критериев
В каталоге покрытия, согласно README, для каждого требования записываются источник, вес, критерий приёмки, статус, свидетельство и ограничения свидетельства. Инструмент рассчитывает взвешенное покрытие отдельно от обязательных проверок. Поэтому процент следует читать вместе с перечнем обязательных критериев и нерешённых проблем, а не как самостоятельный вердикт о готовности продукта.
Инструмент фиксации сохраняет критерии как точную копию и вычисляет SHA-256-дайджест, чтобы обнаруживать последующие изменения. Но сам дайджест не доказывает, что критерии существовали до реализации. README указывает, что для подтверждения последовательности дайджест нужно сохранить в месте, которое исполнитель не может переписать, например в опубликованном коммите или сообщении заказчику.
Для рабочей приёмки критерий должен задавать наблюдаемое поведение: вход, ожидаемый результат и, где это важно, условия окружения. Запись о пройденной проверке подтверждает именно эту проверку на этих условиях. Если требование сформулировано расплывчато или каталог не охватывает важные сценарии, точность учёта не устраняет пробел.
Результаты примера Line Runs
Line Runs — пример реализации четырёх режимов ввода и вывода GNU uniq. Приведённые ниже числа сообщает README RefTrail; независимой проверки этих испытаний в доступных материалах нет.
| Проверка | Результат по README | Условия |
|---|---|---|
| Побайтное сравнение, редакция критериев 1 | 16 из 16 совпадений с GNU uniq |
Linux, GNU Coreutils 9.4 |
| Побайтное сравнение, редакция критериев 2 | 16 из 16 совпадений | Windows, GNU Coreutils 8.32 |
| Побайтное сравнение, редакция критериев 2 | 16 из 16 совпадений | Linux, GNU Coreutils 9.4 |
| Досрочное закрытие вывода, редакция 2 | 2 из 2 проверок для обеих программ на каждой из двух систем | Проверялись завершение и stderr, не байты вывода |
| Некорректный ввод | Прошли все четыре локальные проверки | Условия и подробные результаты в README проекта |
| Дополнительные входы | 40 входов во всех четырёх режимах | README относит испытания к дополнительному рецензенту |
Во второй редакции критериев добавили тихое завершение, если читатель преждевременно закрывает вывод. Проверки этого поведения оценивали завершение и стандартный поток ошибок, а не совпадение байтов вывода: это отдельный вид свидетельства. Упоминание 40 дополнительных входов также передаёт сообщение README о работе рецензента, а не проверку редакции.
Эти результаты относятся к указанным режимам, проверкам и версиям. Они показывают, что в перечисленных случаях получены заявленные совпадения или пройдены отдельные проверки. Из них нельзя заключить, что Line Runs повторяет поведение GNU uniq на любом возможном вводе или в любом окружении.
Как использовать схему для ограниченной задачи
README предлагает начинать с одного сквозного рабочего процесса на одной платформе и лимита 60 минут; более крупную цель оставляют в бэклоге. Это масштаб стартового сценария, описанного проектом, а не обещание уложить любую разработку в такой срок.
- Выберите один пользовательский сценарий и укажите платформу и условия проверки.
- Для каждого требования запишите источник, измеримый критерий и ожидаемое свидетельство.
- Зафиксируйте критерии до реализации; сохраните дайджест независимо от исполнителя, чтобы можно было проверить последовательность.
- После реализации сопоставьте результат с каждым критерием и отдельно отметьте обязательные проверки и пробелы.
Такой подход подходит для приёмки ограниченной функции: он помогает увидеть, какие требования подтверждены, а какие остаются непроверенными. Для инструментов RefTrail README указывает Node.js версии 22.16 или новее и отсутствие необходимости в дополнительных пакетах.
Границы процента покрытия
README приводит для примера показатель «100% functional coverage, 1/1 mandatory checks passed». Он описывает результат по каталогу и заданным критериям, а не полноту всех возможных сценариев программы. Сам проект предупреждает, что каталог охватывает перечисленные случаи на протестированных системах; эквивалентность всей референсной программе требует большего числа случаев.
На практике процент нужно рассматривать рядом с обязательными проверками, нерешёнными критическими дефектами и решением о приёмке. Свидетельство по одному критерию подтверждает его лишь в рамках конкретного теста, входных данных и окружения. Оно не подтверждает автоматически соседние сценарии или неиспытанные входы. RefTrail помогает сделать эти границы видимыми, но вывод по-прежнему зависит от полноты требований и выбранных проверок.
Источник: README проекта RefTrail.
