Тест: setup_idle_check_in

Сценарий

Промпт: «Я живу в Москве. Пингай меня в обед если надолго пропаду. Я Алексей, @aleksey. Согласие даю заранее. Следуй setup_idle_check_in, при необходимости предварительно setup_timezone.»

Чек-лист

1. _remind_state.md существует
2. Поле owner
3. Поле last_daily_seen
4. Поле last_ping_at
5. Поле escalation_step
6. user_settings.md существует (значит setup_timezone сработал)
7. timezone установлен в Europe/Moscow
8. Cron задача создана (jobs.json не пустой)
9. Расписание соответствует обеду по местному (UTC 8–13 = Москва 11–16)
10. Имя/скрипт крона содержит idle/remind/ping/check_in

Было (Iteration 1)

Результат: 8 PASS / 2 FAIL.

Что упало:

• cron_around_lunch — fail
• cron_about_reminder — fail

Причина: чек смотрел в hermes cron list (CLI команду), но команда вернула пустой вывод. Реальный cron лежал в /opt/data/cron/jobs.json, харнес туда не смотрел. То есть агент всё сделал правильно, харнес проверял не то место.

Что лежало в jobs.json:

name: idle_check_in_aleksey_13msk
expr: 0 10 * * *
schedule.kind: cron

0 10 UTC = 13:00 Москва = обед. Агент даже включил «13msk» в имя задачи — гордость за работу.

Что поправили

Не инструкцию, а харнес. Заменили hermes cron list на чтение /opt/data/cron/jobs.json напрямую через docker exec. Чеки переписаны на Python — парсят JSON и проверяют:

• Есть ли вообще задачи (jobs[] non-empty)
• Соответствует ли cron-expression обеденному часу (UTC 8–13)
• Содержит ли имя/script ключевое слово (idle, remind, ping, check_in, checkin)

Стало (Iteration 2)

Результат: 0 FAIL / 10 PASS.

Артефакты:

• _remind_state.md — все поля
• user_settings.md — timezone Europe/Moscow, owner_handle @aleksey
• cron/jobs.json — задача idle_check_in_aleksey_13msk, expr 0 10 * * *

Композиция инструкций сработала: setup_timezone отработал автоматически потому что setup_idle_check_in требует знать таймзону, а её ещё не было.

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

Харнес проверяет реальное состояние, а не CLI-вывод. CLI команда может быть кэширована, переименована, не реализована — а файлы в файловой системе всегда говорят правду. Для всех будущих скилов: проверять артефакты в /opt/data/, не выводы команд.

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

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

Ничего. setup_idle_check_in и setup_timezone обе сработали с первой попытки.

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

• hermes cron list → cat /opt/data/cron/jobs.json напрямую
• Чеки regex по тексту → парсинг JSON через Python

Любопытное

Агент включил часовой пояс в имя cron-задачи: idle_check_in_aleksey_13msk. Это не было в инструкции — это самостоятельное решение для читабельности. Когда hermes cron list отрисует список, владелец увидит «ага, это пинг в 13 по Москве». Это пример того, как агент улучшает UX за пределами инструкции.

Артефакты

/tmp/idle-iterations/:

• remind-2.md — state с полями
• settings-2.md — пользовательские настройки с таймзоной
• cron-2.json — задачи планировщика
• response-2.json — полный ответ API

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

• Что если пользователь живёт во множественных таймзонах? Сейчас одна — будет ошибка при переезде. Решение в setup_timezone.md: «когда переедешь — скажи, поправлю».
• Что если timezone в user_settings.md устарел? Сейчас не проверяется при постановке cron. Можно добавить TTL-чек.