Как harness дорабатывает себя

После добавления журнала и policy появляется следующая задача: runner возвращает done, когда checks пуст. Это изменение уже можно поручить предыдущей версии harness. Она применит предложенный код новой версии и запустит проверки, а человек примет результат.

В этой главе self-hosting означает использование harness для разработки самого harness. Размещение сайта или сервиса на собственном сервере - другое значение того же слова.

Что уже делает учебная цепочка

Исполнитель	Результат	Фактическая проверка
Человек	v01.	Разбор кода и пробный запуск.
v01	v02 из fixture.	py_compile; сообщения только в терминале.
v02	Дневник и сводка ALGI.	Три unit-теста и JSONL-журнал.
v02	v03 из fixture.	py_compile и журнал v02.
v03	Отчёт ALGI.	Пять тестов, проверки policy и журнал v03.

Эта цепочка демонстрирует передачу работы от версии к версии. Самостоятельной генерации новой программы моделью здесь нет: исходники уже лежат в fixtures. Чтобы получить такой режим, нужно подключить backend и расширить проверку его результата.

Следующая задача: запрет пустых проверок

Сформулируйте изменение v04: если в задаче нет обязательных проверок, runner отклоняет задачу до применения backend. Зафиксируйте сообщение, код завершения и событие журнала. Добавьте обычную задачу с тестом, задачу без поля checks и задачу с пустым списком.

Новую версию собирайте в отдельной папке. Выполняет сборку принятый v03; полученный v04 не подменяет его во время запуска. Если v04 окажется сломанным, останется рабочий инструмент для следующей попытки.

При этом текущая policy v03 не разрешает запись runner.py и каталога policies. Для задачи на сам harness владелец должен подготовить отдельную policy с нужными путями и командами проверок. Нельзя поручать кандидату самому расширять разрешения, под которыми принимается его изменение.

Кто проверяет новую версию

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

Проверяющий runner запускает кандидата на сохранённых задачах и сверяет результат: код завершения, события, изменения файлов. Для пустого checks отдельно проверяется, что backend не успел записать файлы. Синтаксической проверки здесь недостаточно.

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

Не меняйте правила посреди задачи

Рабочий запуск выполняет заданную задачу и сохраняет результат. Найденную проблему можно оформить предложением: изменить инструкцию, добавить тест, исправить tool или runner. Принятие такого предложения происходит отдельно, по журналам и проверкам.

Например, два запуска подряд потеряли начало длинного stderr. Это основание для задачи на хранение полного вывода. Успешное выполнение случайной задачи ещё не основание переписывать постоянные правила проекта.

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

С чего удобно продолжить

После отказа при пустом checks можно добавить уникальные ID запусков, тайм-аут команды или сводку журнала. У каждого изменения есть понятный вход и наблюдаемый результат. Изменения доступа к секретам, изоляции и приёмки потребуют другого набора проверок и владельца, который понимает последствия.

В финальном проекте выберите одну такую доработку, проведите её через предыдущую версию harness и покажите задачу, на которой новая версия полезна.