Тема
Финальный проект
Сделайте одну доработку harness и примените полученную версию к задаче ALGI или своего проекта. По результату должно быть понятно, какая проблема возникала раньше, как изменился runner и чем проверено исправление.
Выберите небольшое изменение
Для продолжения учебной цепочки подойдут отказ при пустом checks, уникальный ID запуска, тайм-аут проверки или отчёт по JSONL-журналу. В каждом случае сначала воспроизведите исходное поведение и опишите нужный результат.
Например, для тайм-аута нужна проверка с намеренно долгой командой в тестовом окружении. Недостаточно проверить, что runner вернулся вовремя: дочерний процесс тоже должен завершиться, журнал - содержать причину, а результат - отличаться от успеха.
Продуктовую задачу выбирайте так, чтобы она использовала доработку. После добавления отчёта о запуске можно поручить harness исправление валидации ALGI и передать полученный отчёт на ревью. Саму реализацию ALGI не добавляйте вручную: она должна пройти через построенный вами harness.
Порядок работы
- Сохраните исходную версию harness и воспроизведите проблему.
- Напишите спецификацию изменения, задачу и сценарии приёмки.
- Подготовьте рабочую папку и policy для изменения harness.
- Через предыдущий runner получите кандидата новой версии.
- Проверьте кандидата независимым набором сценариев и проведите ревью.
- Через принятую версию выполните продуктовую задачу.
- Покажите результаты обоих запусков и оставшиеся ограничения.
Если используете fixtures, отметьте это в README. Если подключили модель, укажите backend, переданный контекст, ограничения и результаты фактических запусков. Эти варианты демонстрируют разные части работы, и оценивать их нужно соответственно.
Что оставить в репозитории
| Материал | Что по нему проверяют |
|---|---|
| Спецификация и задача | Проблему, границы изменения и условия остановки. |
| Контекст и policy | Какие сведения и права получил исполнитель. |
| Исходный и полученный runner | Сам diff инструмента. |
| Набор приёмки | Обычный случай, исходный сбой и проверки прежнего поведения. |
| Журналы двух этапов | Кто собрал harness и кто выполнил продуктовую задачу. |
| Описание продуктового изменения | Результат, тесты и решение ревью. |
| README с командами | Повторение работы в чистой папке, требования к окружению. |
Укажите также время подготовки и ревью, число попыток и расходы на backend, если он использовался. Не нужно строить отдельную панель метрик для одного проекта; таблицы фактических затрат достаточно.
Как принимать результат
Попросите другого разработчика повторить команды из чистой копии. Он должен получить ожидаемый результат и найти причину намеренно неуспешного запуска без ваших пояснений.
Затем проверьте границы работы: кандидат не менял приёмочные условия без ревью, запрещённые действия не произошли, частичные изменения и неполные проверки явно отражены в отчёте. Если что-то осталось ручным, укажите кто и на каком шаге это делает.
Готовность проекта определяется этими наблюдениями. Количество подключённых агентов, размер runner и наличие интерфейса сами по себе ничего не добавляют к приёмке.