hermes-hub/agents/inbox/2026-08-23-A17-antigravity-pro-honest-status.md

# Задание A17 (Antigravity Pro): честный статус аккаунта и настоящая проверка

## Дата поступления
2026-08-23

## База
Проверочный HEAD на момент выдачи: **`fb23bff`**.

## Ветка
`antigravity/honest-status`

---

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

```
cd <каталог репозитория>; git fetch origin --prune; git status
git checkout main; git pull --ff-only origin main
git checkout -b antigravity/honest-status
```

**Сначала коммит, потом push.** В прошлый раз работа A15 была выполнена целиком, но осталась незакоммиченной в рабочем каталоге — git в вашем окружении был недоступен, и ветка в `origin` оказалась пустой. Её нашли случайно.

Если git снова недоступен — **скажите об этом первой строкой отчёта**, а не в предупреждении под ним. Это меняет весь порядок приёмки.

В конце:

```
git status                                              <- дерево чистое
git log --oneline -1 origin/antigravity/honest-status   <- ваш коммит
```

---

## Что принято по A15

Веб-API и вынесение действий в общий `ActionExecutor` — правильная архитектура, и она работает. Порт путей на Linux почти закрыт: осталось одно место, `hermes_hub_app.py:37`.

Но в сданном виде **не работало ни то, ни другое**, и это важнее похвалы:

1. **Десктоп был уничтожен.** При выносе действий пропало объявление `class HermesHubApp` вместе с 13 методами каркаса — `__init__`, `_build_layout`, `_create_view`, `_show_view`, `_refresh_data`. Оставшиеся 14 методов оказались вложены **внутрь функции `_load_saved_theme` после её `return`** — синтаксически валидный недостижимый код. Поэтому модуль импортировался, и дефект выглядел безобидным, а `launch_hub()` упал бы с `NameError`.

2. **Веб-API падал с 500 на обоих значимых эндпоинтах**: `get_auth_token` и `run_server` читали `config.hub`, которого у `RouterConfig` нет. Работал только `/api/health` — у него нет проверки авторизации, из-за чего сервер и выглядел поднявшимся.

3. **`do_save_settings` при переносе потеряла** атомарную запись через `os.replace`, `ensure_ascii=False` и вызов `set_refresh_interval` — интервал обновления квот из настроек перестал применяться.

Всё восстановлено ревьюером. Урок один и он общий для проекта: **крупное перемещение кода проверяется запуском того, что перемещали.** Импорт модуля ничего не доказывает — Python примет и недостижимый код.

---

## Главное: «Работает» — вымышленный статус

Владелец сообщил про два аккаунта: «стоит опенкод аккаунт, который не подключён… аккаунт не работает» и «и грок не работает». Оба показаны зелёным **«Работает»**.

По одному из них причина найдена и уже исправлена: адаптер OpenCode не читал сохранённый ключ (`fb23bff`). Но осталась причина, общая для обоих и более глубокая.

`unified_health.py:429` — `STATUS_HEALTHY` с подписью «Работает» назначается в **ветке `else`**, когда ни одно условие отказа не совпало:

```
1. не enabled            -> Отключён
2. нет учётных данных    -> Аккаунт не добавлен / Требуется вход / Холодный резерв
3. cooldown или квота    -> Квота исчерпана
4. rate limit            -> Лимит запросов
5. precord.overall_state -> Ошибка
6. иначе                 -> «Работает»     <- сюда попадает всё непроверенное
```

Состояния отказа берутся из `precord` — записей health tracker, которые появляются **только после настоящего сбоя в бою**. Профиль, который ни разу не вызывали, автоматически получает зелёное «Работает».

**То есть надпись означает «мы не знаем о проблемах», а подана как утверждение, что аккаунт работает.** Это тот же класс дефекта, из-за которого в первом аудите проекта были удалены выдуманные проценты квот: отсутствие данных выдаётся за положительный результат.

### Что требуется

1. **Различать «проверено и работает» и «не проверялось».** Профиль без подтверждения не должен выглядеть так же, как подтверждённо рабочий. Формулировку выберите сами, но она обязана быть честной: «Не проверялся» — правда, «Работает» — нет.

2. **Хранить результат и время последней успешной проверки** рядом с профилем и отдавать их в снапшоте. Интерфейсу нужно показать «проверено 12:05», а не только цвет.

3. Состояние отказа по-прежнему приходит из боевых сбоев — это правильно и ломать не нужно.

**Тест:** профиль со свежесохранёнными учётными данными и без единой проверки не получает статус, утверждающий работоспособность.

## P0-2. «Проверить подключение» ничего не проверяет

`do_test_profile` проверяет наличие учётных данных и доступность локального runtime — и **никогда не вызывает модель**. Поэтому Grok эту проверку проходит и всё равно не работает.

Так сложилось не случайно: требование «тест не должен запускать OAuth и открывать браузер» стоит в проекте с первого аудита, и ради него вызов модели убрали целиком. Требование верное, но реализация выплеснула вместе с ним смысл проверки.

**Требуется настоящая проверка**, не нарушающая прежнего запрета:

- минимальный реальный вызов к провайдеру — самый дешёвый из возможных, с жёстким таймаутом;
- **интерактивный вход не запускается ни при каких условиях**: просроченные учётные данные дают ошибку «Авторизация истекла», а не окно браузера. Для Antigravity это уже обеспечено флагами `BROWSER=none` и `CI=1` в окружении подпроцесса и проверкой срока токена до вызова;
- результат сохраняется как последняя проверка (P0-1) с временем;
- по каждому провайдеру в отчёте: что именно вызывается и сколько это стоит владельцу. Если у провайдера нет дешёвого способа — **сказать об этом прямо**, а не имитировать проверку.

Осторожно с ценой: у владельца шесть аккаунтов Antigravity, три Codex, три OpenCode. Проверка всех подряд не должна съедать квоту. Массовую проверку делать по явной команде, а не автоматически при каждом обновлении.

**Тест:** просроченные учётные данные дают ошибку авторизации без попытки интерактивного входа; успешная проверка фиксируется с временем.

## P1-3. Остаток порта на Linux

`hermes_hub_app.py:37` по-прежнему читает `LOCALAPPDATA` напрямую:

```python
_LOCAL = Path(os.environ.get("LOCALAPPDATA", ""))
```

На Linux это даст пустой путь. Провести через `paths.get_hermes_home()`, как остальные семь мест.

В `agy_subprocess.py` два оставшихся упоминания трогать не нужно: строка 41 — комментарий, строка 414 — список переменных окружения, пробрасываемых подпроцессу на Windows, и он там уместен.

---

## Ограничения

- Параллельно идут **A18** (смена модели) и **A19** (установщики). Ваши файлы: `unified_health.py`, `health_tracker.py`, `action_handler.py`, `adapters/**`, `state_store.py`, `hermes_hub_app.py`, `docs/UI_STATE_CONTRACT.md`, `docs/web-api/CONTRACT.md`. **Не ваши:** `router/web/**`, `router/ui/**`, `model_discovery*`, `installer/**`, `launcher/**`.
- Меняете снапшот — правьте `docs/web-api/CONTRACT.md` и скажите об этом в отчёте: против него пишется клиент.
- Никаких статусов без основания. Нет проверки — так и написать.
- Тег `v0.1.1` не создавать.

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

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

## Главное

Зелёная галочка на нерабочем аккаунте — худший вид лжи в этом продукте: она не просто бесполезна, она уводит от поиска настоящей причины. Владелец потратил на это два обращения. Лучше честное «не проверялся», чем уверенное «работает».

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