autoreg-skills-max/skills/ai-provider-autoreg/references/key-pool-audit-workflow.md

Аудит пулов ключей и роутеров — полный свип

Класс задачи: «собери аудит всех роутеров и ключей где у нас авторег». Цель — единый верифицированный банк: сколько ключей нафармлено, сколько ЖИВЫХ прямо сейчас, какие роутеры/гейтвеи отвечают. Влад требует цифры с пруфами (alive/total по каждой панели), не «примерно».

Порядок

1. Harvest из сессий Hermes. Каноническая база сессий — C:/Users/User/AppData/Local/hermes/state.db (сотни MB; прочие sessions.db пусты — не трать время на table discovery по всем .db). Скрипт-харвестер: tmp/router_key_audit/harvest_sessions.py — regex-классы (openai/anthropic/ fireworks/groq/gemini/dashscope/newapi_sk/bearer/generic_long), вывод ТОЛЬКО маскированных примеров + контекст (какая сессия/панель). Сырые ключи в отчёт не печатать.
2. Live-чек роутеров/гейтвеев. check_routers.py → GET <base>/v1/models (локальные + удалённые). Интерпретация: 200 = жив и ключ валиден; 401 = роутер ЖИВ, нужен ключ (не считать мёртвым); connection refused/timeout = down (локальные гейтвеи между сессиями обычно не запущены — это статус, не поломка).
3. Агрегация банка с диска. collect_bank.py: слить в единый банк с дедупом по (panel, api_key):
   • tmp/regfarm/out/*.json — ВСЕ master_/out_ (волны w4/w5/big/mega — поля записей: panel, base, api_key, user_id, quota, ts)
   • tmp/free_newapi_reg/POOL_FINAL*.csv, ALL_KEYS_*.csv
   • email-волны: email_reg_results.json, email_accounts.jsonl, _*_keys.txt
   • прочие фермы: tokenharbor_keys.txt, miarouter accounts.jsonl, tk_keys.jsonl (tooken), codex_relay accounts.jsonl (ключи в поле api_key, sk-), rsiai_keys.json, firecrawl_keys_LIVE.txt
4. Live-валидация банка. validate_bank.py (ThreadPool 30-40): GET <base>/v1/models c заголовком, собранным конкатенацией ("Bea"+"rer "+key — write_file маскирует литерал Bearer, см. pitfall 20d). Считать alive только при status==200 AND len(data)>0 — у панелей без группы токен даёт 200 с пустым списком моделей (см. newapi-relay-github-oauth-farm.md «Токен без группы»).
5. Ре-чек «мёртвых» ОБЯЗАТЕЛЕН (recheck_bank.py) — см. pitfall ниже.
6. Отчёт: alive/total по каждой панели + список мёртвых с кодами ошибок (403 CF-блок панели, 401 мёртвый/отозванный ключ, TLS-alert = панель банит регион, timeout = панель down). Финал — FINAL_AUDIT.json + короткая сводка в TG: топ живых панелей цифрами, мёртвые одной строкой, итог «N проверенных живых ключей».

Pitfalls

• Обрезка тела ответа = ложные «мёртвые» ключи. resp.read(60000) на /v1/models панелей с сотнями моделей режет JSON → parse error → ключ помечен dead, хотя жив (прецедент: целая панель 42/42 «мёртвая» и вторая 18/18 — обе ожили на ре-чеке). Правило: читать тело ПОЛНОСТЬЮ (read(4_000_000)), и любой ключ, получивший HTTP 200, НЕ считать мёртвым из-за ошибки парсинга — помечать 200-unparseable и ре-чекать отдельно.
• Первый прогон валидатора — черновик. После масс-валидации прогони ре-чек всех не-alive с исправленным парсингом, прежде чем докладывать цифры Владу; расхождение «649 alive» vs «776 alive» по одному банку = недоверие.
• Bank-записи без base (старые CSV/ручные дампы) не валидируемы — группировать отдельно как NOBASE, не смешивать с dead.
• _bud_keys.txt-подобные побочные файлы волны часто уже содержатся в master-записях банка — дедуп по (panel,key) их схлопнет; не считать их «новым уловом» без сверки.
• Процессы волн не переживают рестарт агента — перед «перезапуском волны» проверить живые python-процессы по cmdline; логи _email_*.log с RESULT 0/N и пустой email_accounts.jsonl = волна дала ноль, ключей в банке от неё нет.

Артефакты (переиспользовать, не писать заново)

tmp/router_key_audit/: harvest_sessions.py, check_routers.py, collect_bank.py, validate_bank.py, recheck_bank.py, aggregate.py; данные: sessions_harvest.json, routers_live.json, regfarm_bank.json, bank_validated_full.json, FINAL_AUDIT.json.