Проверка самого harness

Тесты ALGI проверяют продуктовые функции. У runner другая ответственность: применить результат в нужной папке, запустить обязательные проверки, правильно обработать отказ и сообщить, чем закончилась работа. Ошибка runner может пропустить неверный результат даже при хороших тестах продукта.

В задачах сборки v02 и v03 пока есть только py_compile. Он проверяет синтаксис файла. Для проверки поведения runner нужен отдельный набор сценариев.

Начните с таблицы ожидаемых результатов

Сценарий	Ожидание	Что проверять кроме статуса
Обычная задача ALGI	done, код 0.	Нужные файлы появились, тесты действительно запускались.
Отсутствует спецификация	blocked, код 2.	Backend не применял изменения, есть context_missing.
Запрещённая команда	blocked, код 2.	Для этой команды нет check_started, есть отказ policy.
Упавший тест	failed, код 1.	Сохранены код завершения и сообщение об ошибке.
Запись за пределы разрешённых путей	blocked, код 2.	Запрещённый файл не появился.
Пустой checks	Требуется отказ в приёмке.	Текущие версии ошибочно возвращают done.

Последняя строка описывает обнаруженный пробел. В коде используется all(...), а для пустого набора результат True. Runner может объявить успех, не выполнив ни одной проверки. Формулировка «все проверки прошли» формально совпадает с кодом, но плохо соответствует ожиданию автора задачи.

Проверяйте побочный эффект отдельно

Статуса blocked недостаточно. Запрещённое действие могло уже произойти, а отказ появиться позже. Для записи проверяйте файловую систему после запуска; для команды используйте тестовый исполнитель или маркер, по которому видно, вызывалась ли она.

У v03 применение fixture не является одной атомарной операцией. Если первые файлы разрешены, а следующий запрещён, первые уже записаны. Также отказ одного check не останавливает обход остальных. Ожидание «после отказа вообще ничего не изменилось и ничего не запускалось» текущая реализация не обеспечивает.

Проверять это нужно на отдельной временной рабочей копии с синтетическими данными. Удаление копии и новый запуск удобнее, чем попытка угадать, какие частичные изменения остались.

Воспроизводимый запуск и replay

Для повторения нужны задача, fixture, начальное состояние рабочей папки, policy, версия runner и окружение Python. Зафиксируйте их версии. Журнал полезен для сравнения, но сам по себе не содержит все эти входы.

Fixture позволяет повторять один и тот же подготовленный ответ. Реальный backend может выдавать разные изменения при той же задаче. При сравнении двух версий harness разделяйте эти режимы: детерминированная проверка управляющего кода и серия запусков с моделью отвечают на разные вопросы.

В проверках модели сохраните задачи, которые не использовались при настройке инструкции. Иначе улучшение может означать подгонку под знакомые примеры. Отдельно храните ранее исправленные ошибки, чтобы новая настройка не вернула их.

Как проверить пользу доработки

Допустим, новая версия сокращает контекст. Сравните её со старой на одинаковом наборе задач и при одинаковых ограничениях времени и числа попыток. Измерьте долю принятых результатов, ошибочно принятых результатов и время ревью. Количество токенов поможет объяснить разницу в расходах, но не заменит эти показатели.

Меняйте по одному фактору: сжатие контекста, поиск по памяти, модель или дополнительное ревью. Такое отключение отдельных механизмов называют ablation. Если одновременно заменить всё, причина изменения результата останется неизвестной.

Если результаты неожиданно ухудшились, сначала проверьте сам стенд: доступность зависимостей, правильность исходных данных, ожидания тестов. Ошибка оценщика выглядит в таблице так же, как ошибка агента.

От инцидента к новому сценарию

Возьмите неудачный запуск, удалите личные данные и секреты, затем сократите его до входа, который воспроизводит ошибку. Зафиксируйте ожидаемое поведение. После исправления этот сценарий входит в обязательный набор перед обновлением runner или backend.

Для ALGI таким случаем может стать заметка с контактом. Для harness - пустой набор проверок или столкновение идентификаторов двух запусков. Их следует тестировать отдельно, поскольку исправляются они в разных частях системы.

Задание для следующей версии

Составьте набор проверок для v03, включая пустой checks. Затем опишите задачу на исправление этого поведения: когда именно должен происходить отказ и какое событие попадёт в журнал. Лучше обнаружить отсутствие обязательных проверок до применения backend, чтобы не оставлять ненужный diff.

Это подходящая доработка для v04. Её нужно собрать через предыдущий harness и проверить независимым набором сценариев. Порядок такой работы разобран в главе о доработке самого harness.