# Промпт для Sonnet — код-ревью drhider (скорость + сбои)

## Роль
Ты — ревьюер кода. Отвечай ТОЛЬКО по делу: короткие технические тезисы. Без воды, без лирики, без «как было бы здорово», без общих фраз. Каждый тезис — конкретика: файл, функция, строка, суть.

## Ограничение: смотреть ТОЛЬКО эти файлы, нигде больше не рыться
- `drhider/obfuscator.py` — двухпроходный обфускатор (проход 1: извлечение текста + regex + LLM NER; проход 2: замена)
- `drhider/extractor.py` — pdf_to_markdown (pdfplumber), doc_to_markdown (сервис liberta), expand_zips (рекурсия zip, CP437→CP866), защита от zip-бомб
- `drhider/scanner.py` — scan_regex, scan_llm_ner
- `drhider/replacer.py` — apply_replacements (один regex из всех ключей)
- `drhider/llm_client.py` — OpenAI-совместимый клиент, счётчики токенов/времени
- `drhider/builder.py` — build_zip, build_mapping_csv
- `site/routes/api_bp.py` — upload, process_stream (SSE + воркер в потоке), download/csv
- `site/app.py` — create_app, лимиты, setup_logging (LOG_LEVEL/LOG_FILE)
- `site/session.py` — хранение сессий в памяти, TTL 30 мин, MAX_SESSION_BYTES
- `site/templates/index.html` — фронт: нативный unzip, таблица, SSE-прогресс, таймеры, лимиты 100МБ/1ГБ

Не читай README, docs, History, tests, Dockerfile, ничего про деплой.

## Контекст: сбои, которые были (объясни каждый, если увидишь первопричину в коде)
1. «SSE connection failed» при живом воркере. Выяснено: воркер падал на битом PDF — `PDFSyntaxError('No /Root object!')` в `extract_text` не был обёрнут по-файлово; после фикса (skip битого файла) SSE доходит до complete. Подтверди/опровергни по коду, есть ли ещё места, где одна ошибка файла роняет весь проход.
2. Кракозябры кириллицы в именах zip. Причина: Info-ZIP пишет UTF-8 без флага 0x800 → декодер `encode(cp437).decode(cp866)` ломает. Проверь `_decode_name` в extractor.py: покрывает ли оба реальных сценария (CP866 без флага и UTF-8 с флагом), есть ли дыры.
3. HTTP 413 при загрузке. Лимиты: MAX_CONTENT_LENGTH=200MB (запрос), MAX_SESSION_BYTES=500MB (сессия). Фронт пускает до 100МБ/файл и 1ГБ/сумма — рассинхрон фронт/бэк. Отметь.

## Главная задача: предложи БОЛЕЕ БЫСТРУЮ логику обработки
Известные факты производительности (факты, не догадки):
- pdfplumber на скане Spartan10Manual.pdf 14.8 МБ — 70–470 секунд на извлечение текста.
- Большой PDF 19 МБ — ~25–26 с на extract_text.
- LLM NER — один общий вызов на все файлы, ~1.8с на маленьком наборе, зависит от числа токенов.
- apply_replacements оптимизирован (один regex), но проверить, нет ли лишней работы.

Что хочешь от тебя:
- Где реальные узкие места в коде (не «вообще», а конкретные функции/строки).
- Конкретные предложения ускорения: что менять, как, ожидаемый эффект. Без «использовать PyMuPDF» — уже пробовали, теряет таблицы (94 vs 40), ТАБЛИЦЫ КРИТИЧНЫ. Учитывай это ограничение.
- Можно ли ускорить без смены pdfplumber (параллельность страниц, кэши, ограничение повторных парсингов, предобработка)?
- Есть ли дублирующая работа между проходами 1 и 2 (например, повторный парсинг/чтение)?
- Безопасно ли распараллелить извлечение текста по файлам (потоки/GIL)? Если да — как.

## Формат ответа
- Секция «Сбои»: по каждому — подтверждение/опровержение по коду + где именно.
- Секция «Узкие места»: список файл:строка + суть + почему.
- Секция «Предложения ускорения»: пронумерованный список, каждый пункт: что/где/как/эффект/риски.
- Секция «Итог»: 3–5 самых важных действий по приоритету.
- Максимум — сухо, без воды.