Журнал запуска

Runner завершился с failed. В терминале видно только итог, а причина осталась в выводе команды, которая выполнялась несколько минут назад. Для разбора нужен журнал, связывающий задачу, изменения и проверки.

В v02 он хранится в формате JSONL: одна JSON-запись на строку. Такой файл можно читать обычным скриптом, фильтровать по типу события и прикладывать к результату задачи.

Найдите журнал своей задачи

После запуска ALGI runner печатает строку log: .... Файл лежит в runs/ рядом с тем runner.py, который выполнял задачу. Рабочая папка продукта и папка журналов могут быть разными.

Список журналов после прохождения практики:

find "$LAB_ROOT/harness-v02/runs" "$LAB_ROOT/harness-v03/runs" \
  -maxdepth 1 -name '*.jsonl' -type f

Выберите файл задачи algi-02-clinician-report из harness-v03/runs. В нём должна быть такая последовательность; ниже схематическая выдержка, время и часть полей опущены:

{"event":"task_loaded","task_id":"algi-02-clinician-report"}
{"event":"context_ready","files":["specs/pain-diary.bdd.md","AGENTS.md","specs/pain-diary.bdd.md","algi/domain.py","tests/test_domain.py"]}
{"event":"backend_started","backend":"scripted"}
{"event":"policy_check","action":"write_file","path":"algi/domain.py","allowed":true}
{"event":"file_written","path":"algi/domain.py"}
{"event":"policy_check","check":"unit tests","allowed":true}
{"event":"check_started","check":"unit tests"}
{"event":"check_finished","check":"unit tests","exit_code":0}
{"event":"result_classified","result":"done","reason":"all checks passed"}

Повтор пути к спецификации в files не опечатка: runner добавляет поле spec к списку context, где тот же путь указан ещё раз.

Восстановите причину результата

Начните с последнего result_classified. При failed найдите check_finished с ненулевым кодом, прочитайте stderr и stdout, затем определите, что это было: провал assert, ошибка импорта, отсутствие команды или проблема окружения.

При blocked ищите более раннее событие отказа: context_missing, backend_blocked или check_blocked. Причины требуют разных действий. Отсутствующую спецификацию нужно восстановить; запрещённую команду - обсудить или заменить разрешённой операцией; повтор того же запроса ничего не исправит.

Текущий v03 не перехватывает все исключения. Если result_classified отсутствует, проверьте код завершения процесса и его stderr. Нельзя считать такой журнал успешным только потому, что последняя записанная проверка прошла.

Что этот журнал не доказывает

context_ready подтверждает существование файлов, но не чтение их моделью. file_written сообщает путь и размер, но не содержит diff. policy_check подтверждает решение функции runner, но не показывает все действия Python-кода внутри тестов.

У v02 и v03 есть ещё несколько ограничений:

• Сохраняются только последние 4000 символов каждого потока вывода проверки. Начало длинного traceback можно потерять.
• В журнале нет копий или хешей задачи, спецификации и правил доступа. Если файлы изменились, точное окружение прошлого запуска восстановить трудно.
• Идентификатор включает время с точностью до секунды и ID задачи. Два запуска одной задачи в одну секунду могут записать события в один файл.
• Журнал доступен на запись тому же пользователю, который выполняет runner. Он не защищён от изменения исполняемым кодом.

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

Когда понадобятся traces и метрики

Пока runner выполняет одну задачу последовательно, JSONL обычно хватает. При нескольких параллельных задачах добавьте идентификаторы запуска и шага в каждое событие. Для внешних вызовов и долгих проверок полезны начало, конец, длительность и связь с родительским шагом. Из них можно собрать trace и увидеть, где ушло время.

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

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

Отчёт для ревью

По своему журналу заполните отчёт о запуске: задача, фактические изменения, проверки, итог и следующий шаг. Если какой-то ответ пришлось вспоминать, запишите недостающее поле журнала. Если информации в журнале принципиально нет, так и укажите в отчёте.