tui-tester

Этот навык описывает проверку поведенческих изменений и визуального вывода Gemini CLI через терминальную автоматизацию. Его назначение состоит в том, чтобы подтвердить ожидаемые интерактивные действия в терминале, проверить отображение TUI при разных размерах и состояниях окна и не допустить регрессий в уже работающих сценариях. В описании разделены три ответственности: behavioral verification, visual validation и regression testing. Поэтому карточка полезна для изменений CLI, где одного exit code недостаточно и требуется увидеть реальное состояние интерфейса. Критический протокол начинается с активации underlying agent-tui skill: это должно быть первым действием тестового запуска. Затем на macOS или в параллельной среде проверяется глобальный daemon и открывается live preview. Если активной сессии нет, источник предлагает остановить старую tmux-сессию agent-tui, остановить daemon, убрать временные файлы, запустить daemon в foreground и открыть live preview. Эти действия относятся к настройке среды; их смысл — получить отдельный управляемый контур для терминального теста и не смешивать его с личными настройками. После запуска Gemini CLI каждый вызов получает session_id, возвращённый командой agent-tui run; последующие операции должны использовать именно этот идентификатор. Команды выполняются атомарно: за один turn отправляется ровно одна команда, без конвейера действий. Основной цикл выглядит как Action → Wait → Screenshot → Verify → Next Action. Такой порядок отделяет отправку команды от появления результата и заставляет проверить фактический экран перед продолжением. В учебном примере сначала стартует CLI, затем тест ждёт prompt, отправляет одну команду, снова ждёт ожидаемый текст и проверяет вывод. Для Gemini CLI источник требует сначала собрать изменённый проект через npm run build или npm run build:all. Переменная GEMINI_CLI_TRUST_WORKSPACE=true нужна, чтобы убрать модальные окна доверия, способные перехватить фокус; GEMINI_CLI_HOME используется для изоляции конфигурации от личной среды. Эти настройки не заменяют проверки результата: после выполнения всё равно нужно дождаться состояния терминала и сделать screenshot. Навык тем самым задаёт не только команды, но и порядок наблюдения, важный для интерактивного интерфейса. При timeout рекомендуется снять новый screenshot и диагностировать состояние, а ошибка os error 61 считается сигналом для восстановления daemon: его нужно перезапустить тем же tmux-подходом, после чего повторить проверку с чистой сессией. Ограничение навыка очевидно: он даёт протокол и примеры автоматизации, но не определяет ожидаемый текст, сценарии конкретного проекта, визуальные критерии или допустимые различия между терминалами. Их должен задать тестируемый продукт. Результат behavioral или visual проверки нужно связывать с конкретной сборкой и session_id; сам факт успешного запуска agent-tui не доказывает, что интерфейс соответствует требованиям.