Тест: check_layout_render

Дата: 2026-05-22
Harness: hermes-agent/docs/check-layout-iterate.sh
Модель: gpt-5.5
Метрика: 7 PASS / 8 чеков на iteration 2; чек после правки расслаблен — соответствует 8/8

Сценарий

Промпт: «Я только что положил новый layout в /opt/data/secondbrain/_layouts/test/simple.html. Проверь что он компилируется без warnings — следуй instructions/check_layout_render из школы. Покажи результат.»

Перед стартом harness:

  1. Удаляет /usr/local/bin/renderlayout.py из контейнера (агент должен извлечь скрипт из скила или вызвать /_system/renderlayout напрямую)
  2. Инжектит API-ключ в .obsidian/plugins/trip2g/data.json чтобы renderlayout мог получить auth

Чек-лист (8 формальных)

  1. tried_renderlayout — упоминание renderlayout
  2. referenced_target_file — упомянут целевой файл simple.html
  3. returned_preview_url — в ответе есть preview_id=... URL
  4. ran_command — был реальный terminal/python вызов
  5. renderlayout_accessed — агент достучался до renderlayout любым способом: либо извлёк CLI, либо POST через HTTP
  6. reported_result — финальный отчёт с warnings/без
  7. daily_exists — daily note создан
  8. daily_mentions_check — в daily запись о проверке layout

Путь итераций

Iteration 1: 1 FAIL / 7

Чек ran_command упал — мой regex для определения tool calls был синтаксически кривой. Сам агент успешно выполнил всё (вывод показывал renderlayout.py команду и preview URL). Чек оказался дефектом харнеса.

Iteration 2: 1 FAIL / 8

Чек extracted_renderlayout_py упал — агент пошёл прямым путём, через HTTP POST на /_system/renderlayout вместо извлечения Python скрипта из школьной инструкции.

Это не баг — оба пути валидны и дают одинаковый результат. Чек оказался слишком жёстким.

Правка: заменил на renderlayout_accessed (via CLI) OR (via direct HTTP) — принимаем оба варианта. После этого — 8/8.

Iteration 3: не дочитан

Запустил после правки скила (добавил «CLI first» рекомендацию) для проверки что агент теперь предпочитает CLI. Curl таймнул на 300с — агент видимо много работы делает в начале (читает школу, потенциально извлекает Python source). Не блокер: iteration 2 уже доказал что инструкция работает.

Главный вывод

Инструкция работает, агент сам решает между CLI и HTTP. Без явного намёка агент выбрал прямой HTTP — это проще, меньше шагов. После добавления «CLI first» хинта в инструкцию, поведение может измениться (требует iteration 3 для подтверждения).

Чеки нужно делать семантическими. Не «через CLI», а «достучался до сервиса». Реализация не должна жёстко прописываться в харнесе если оба пути валидны.

Что меняли в инструкции

  • Добавлена секция «Сначала — CLI, потом HTTP» в начало (объясняет почему CLI предпочтительнее: тестированный auth, парсинг warnings, exit code)
  • Хинт: «если renderlayout.py не в PATH — извлеки его из кодблока в конце инструкции»

Что меняли в харнесе

  • Чек renderlayout_accessed — принимает CLI или HTTP путь
  • Чек ran_command — поправлен regex для определения tool calls
  • Дополнительно: harness инжектит API ключ в data.json (нужно для auth при любом пути)

Любопытное

Когда среда была "лёгкая" (CLI в PATH) — агент использовал CLI. Когда среды нет — выбрал прямой HTTP как самое простое. Это рациональное поведение: меньше движений, тот же результат.

Если в будущем хотим прицельно тестировать извлечение CLI из школы — нужен отдельный тест-сценарий, не этот. Например, инструкция extract_cli_from_skill с своим харнесом (как раз была попытка субагента её сделать).

Артефакты

/tmp/check-layout-iterations/:

  • response-{N}.json — ответы агента
  • daily-{N}.md — daily-логи
  • found-script-{N}.txt — поиск renderlayout.py на диске после прогона

Открытые вопросы

  • Стоит ли заставлять агента всегда извлекать CLI? Pro: единообразие, проверенный auth. Con: лишний шаг если HTTP всё равно работает.
  • Как тестить «извлечение из школы» отдельно — отдельная инструкция или флаг в harness'е?