hermes-hub/agents/inbox/2026-08-25-A31-preflight-state-batching-pii.md

Задание A31: проверка готовности, состояние прогона, батчинг и персональные данные

Дата поступления

2026-08-25

База

Проверочный HEAD на момент выдачи: 1a21c8b.

Ветка

antigravity/preflight-state-batching

Когда выполнять

После A28, A29 и A30. Задание дорабатывает то, что они закладывают, и раньше их начинать нельзя: пункты P0-1 и P0-2 опираются на реестр ролей из A28 и на механику workflow из A30.

Два прохода: Flash реализует, Pro проводит аудит. Пункт P0-6 написан для аудитора.

---

Порядок работы с git

cd <каталог репозитория>; git fetch origin --prune; git status
git checkout main; git pull --ff-only origin main
git checkout -b antigravity/preflight-state-batching
git commit -m "..."          <- сначала коммит
git push -u origin antigravity/preflight-state-batching

В main напрямую не пушить.

---

Откуда взялось

Владелец передал набор описаний субагентов (Скиллы/, 13 файлов). Ревьюер сверил каждое с текущим кодом. Большая часть уже реализована в Hermes Hub и сильнее шаблонов — их брать не нужно, и это зафиксировано ниже, чтобы к вопросу не возвращались. В задание вошло только то, чего действительно нет.

Что уже есть — не реализовывать заново

Шаблон	Что в проекте вместо него
Model Router	Сам Hub: route_request, цепочки по ролям, обнаружение моделей, set_model
Retry & Fallback Agent	router_engine: цепочки, max_failover_attempts, cooldown, здоровье по семействам, пороги квот из A26
Coordinator (конфликты доступа)	LeaseManager, max_concurrency на профиль — router_config.py:21, применяется в router_engine.py:217
Tool Router	Маршрутизация инструментов — дело Hermes Agent, а не Hub
Test Agent	Дублирует роль tester из A28
Retriever / Chunker / QA	RAG по базе знаний; Hermes Hub не про это
Lyrics-to-Structure, Timing & Pacing, Multimodal Validator	Музыка и озвучка, к продукту отношения не имеют

---

P0-1. Роль «Проверяющий готовность» (Dependency Agent)

Тринадцатая роль в реестре A28.

Обязанности: до начала задачи убедиться, что на месте всё необходимое — исполняемые файлы и CLI, библиотеки, учётные данные, права доступа, доступность локальных серверов. Сообщить о нехватке до запуска, а не посреди прогона.

Обоснование не теоретическое. Проект терял раунды ровно на этом:

• установщик падал с кодом 12, потому что проверочный скрипт был заморожен на 16 профилях;
• веб-сервер не стартовал на Windows: установщик не ставил fastapi и uvicorn;
• gemini отказывался работать без --effort, когда карта моделей была пуста;
• гайд владельца вёл копировать scripts/ag_slot_oauth.py, которого нет ни в репозитории, ни в истории git.

Требуется:

1. Роль заведена в реестре с описанием обязанностей, видимым в интерфейсе.
2. Набор проверок реальный и исполняемый: наличие agy, fastapi, uvicorn, доступность настроенных локальных серверов, наличие учётных данных у профилей в цепочках ролей.
3. Результат — список с причинами, а не «всё плохо». Каждая непройденная проверка называет, чего именно не хватает и что с этим делать.
4. Проверка не должна ходить в сеть к платным провайдерам и жечь квоту.

P0-2. Состояние прогона (State Manager)

Не отдельная роль, а механика внутри workflow из A30. Заводить агента с таким именем не нужно.

Workflow из A30 идёт итерациями с возвратами на доработку. Прогон может прерваться: сервер перезапустили, обновление установилось, машина ушла в перезагрузку. Сейчас всё это теряется.

Требуется хранить и восстанавливать: какие шаги пройдены, какие результаты получены, номер итерации, какой агент был активен. После перезапуска — либо продолжить, либо честно сказать, что прогон прерван и почему. Молчаливая потеря недопустима.

Осторожно: состояние прогона не должно содержать секретов. Смотри P0-4.

P0-3. Батчинг и контекст для локальных моделей

Дополняет A25, который уже влит: adapters/local_adapter.py на месте.

Известное про сервер владельца, снято ревьюером при разведке — заново не выяснять:

192.168.1.81   два сервера llama.cpp, оба OpenAI-совместимые
порт 8081      Qwen3.8-27B-Q4_K_M, reasoning on, контекст 65536
порт 8082      Qwen3-4B-Instruct-2507, reasoning off
оба            --parallel 1, то есть один запрос за раз
видеокарта     Tesla V100-PCIE-32GB, занято 28.7 из 32.7 ГБ

--parallel 1 означает: второй запрос встаёт в очередь. Механизм ограничения у нас есть — LeaseManager с max_concurrency. Требуется убедиться, что для локальных профилей он выставлен в 1 из конфигурации, а не по случайному совпадению с умолчанием, и что при занятом сервере маршрутизация уходит к следующему профилю, а не ждёт.

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

Не выдумывать пределы. Длину контекста и предел одновременных запросов берите у сервера через /v1/models и настройки профиля, а не подставляйте «разумные» числа.

P0-4. Персональные данные в снапшоте

Проверено исполнением: sanitize_snapshot в web/server.py вычищает секреты — access_token, refresh_token, api_key, JWT, Bearer. Почты не маскируются вовсе: слово email в файле не встречается ни разу.

Раньше это было приемлемо: хаб слушал 127.0.0.1. Сейчас у владельца он открыт в домашнюю сеть по 0.0.0.0 с токеном, поверх HTTP. Почты всех подключённых аккаунтов уходят по сети открытым текстом.

Контракт (раздел 3, пункт 4) фиксирует: маскирование — решение владельца, по умолчанию отдаём как есть, потому что интерфейс без опознания аккаунта бесполезен.

Требуется предложить владельцу выбор, а не решить за него:

1. Настройка маскирования почт в снапшоте: полностью, частично (v***@gmail.com) или как есть.
2. При включённом маскировании интерфейс обязан оставаться пригодным: аккаунты должны различаться между собой.
3. Умолчание обосновать в отчёте.

Секреты маскируются всегда и настройке не подлежат.

P0-5. Честность агента контроля затрат

Роль cost-controller заводится в A28. Здесь — предупреждение, которое ей необходимо, иначе она будет врать.

Проверено: поля prompt_tokens, completion_tokens, total_tokens в telemetry_service существуют, но провайдеры их не отдают — в аналитике владельца стоит «Н/Д (не отдаются)».

Значит расход токенов агент может только оценивать. Требуется:

1. Оценка обозначается как оценка. Не выдавать её за измерение.
2. Где провайдер всё же вернул настоящие числа — показывать их отдельно от оценок и помечать.
3. Порог бюджета, построенный на оценке, срабатывает — но владелец должен видеть, что решение принято по оценке.

Это то же правило, что уже дважды спасало проект: отсутствие данных не выдаётся за данные.

P0-6. Аудит вторым проходом

1. Выдуманные значения. Особый риск в P0-3 (пределы контекста) и P0-5 (расход токенов). Ни одного числа, которого не дал провайдер или измерение.
2. Проверки готовности должны действительно исполняться, а не возвращать заранее заготовленный успех. Запустить при намеренно сломанном окружении и убедиться, что причина названа верно.
3. Состояние прогона не содержит секретов — проверить содержимое отдельно.
4. Маскирование не ломает интерфейс: аккаунты остаются различимыми.
5. Побочные изменения объяснить.
6. Пропущенный пункт назвать пропущенным.

---

Ограничения

• Десктоп (router/ui/**) не трогать.
• Не реализовывать заново то, что перечислено в таблице выше как существующее.
• State Manager — механика внутри workflow, а не роль в реестре.
• Действия только через существующий action_handler; новые — с правкой docs/web-api/CONTRACT.md.
• Правило честности без исключений.
• Тег v0.1.1 не создавать.

Критерии приёмки

1. Ветка в origin, git status чист.
2. Роль «Проверяющий готовность» заведена; проверки исполняются по-настоящему; при сломанном окружении названа верная причина — приложить вывод.
3. Прогон workflow переживает перезапуск хаба либо честно сообщает о прерывании с причиной; проверено.
4. Состояние прогона не содержит секретов; проверено отдельно.
5. Для локальных профилей ограничение одновременных вызовов равно 1 и задано конфигурацией; при занятом сервере маршрутизация уходит дальше, а не ждёт; проверено.
6. Пределы контекста берутся у сервера, а не зашиты.
7. Маскирование почт настраивается, умолчание обосновано, аккаунты остаются различимыми.
8. Оценка расхода токенов обозначена как оценка и отличима от измеренных значений.
9. Ни одного выдуманного значения; проверено отдельно.
10. ruff check . чисто; релизный гейт не ухудшен.
11. Отчёт: START_HEAD, FINAL_HEAD, origin/main, git status, X passed / Y skipped / Z failed.

Главное

Четыре доработки, каждая закрывает известную боль: прогон падает посреди работы из-за отсутствующей зависимости; длинный workflow теряется при перезапуске; локальные модели встают в очередь; почты уходят по сети открытым текстом.

Порядок сдачи

Передать точный FINAL_COMMIT_SHA. Сдано только после появления коммита в origin.