docs: сортировка History по темам (sonnet, opus, llm, sse, ux-frontend, upload, infra, plans, tests, base, code-fixes)

History/sonnet/2026-08-20-sonnet-query-review-speed-followup.md

@@ -0,0 +1,53 @@
+# Промпт для Sonnet — follow-up вопросы по ревью (скорость + сбои)
+
+## Контекст
+Ты дал ревью (файл: History/2026-08-20-sonnet-query-review-speed.md). Часть пунктов приняли,
+часть — требуют уточнения. Отвечай ТОЛЬКО на вопросы ниже, сухо, конкретно, без воды.
+Если что-то из твоих утверждений основано на допущении, а не на факте — скажи явно «допущение» и
+что нужно проверить, чтобы подтвердить.
+
+## Вопрос 1. Фильтр `page.lines or page.curves` перед `extract_tables()` (extractor.py)
+Ты предложил: не вызывать extract_tables() на страницах без vector-линий, т.к. на сканах это пустой проход.
+Вопросы:
+1.1. Перечисли КОНКРЕТНО типы таблиц, которые `extract_tables()` находит, но которые НЕ дают
+     `page.lines`/`page.curves` (текстовые сетки, таблицы на заливке/fill, встроенные картинки, что ещё?).
+1.2. Есть ли в нашем реальном наборе (TMP/спецификации, 0144-03-2023_отчет об оценке.pdf, документы из
+     DownLoads) риск, что фильтр отбросит реальную таблицу? Это надо проверить фактом — предложи
+     точный способ замера: как сравнить число таблиц с фильтром и без на конкретных файлах.
+1.3. Насколько `page.lines`/`page.curves` дешевле `extract_tables()`? В pdfplumber они тоже делают
+     парсинг объектов страницы — дай оценку реального выигрыша на скан-PDF, не «в разы», а чем измерить.
+1.4. Безопасная альтернатива: может, стоит вызывать extract_tables() только если `page.find_tables()`
+     вернул непусто? Или это то же самое по стоимости? Уточни, что реально дорого внутри extract_tables().
+
+## Вопрос 2. `_decode_name`: попытка decode("utf-8") перед decode("cp866")
+Ты предложил порядок: raw.decode("utf-8"), при ошибке — raw.decode("cp866").
+2.1. Оцени риск ложного срабатывания: когда CP866-байты случайно образуют валидный UTF-8
+     (например, псевдографика 0xC0-0xDF + продолжения 0x80-0xBF). Насколько это реально для имён
+     файлов 1С? Есть ли способ отличить «настоящий UTF-8» от «случайного» (например, проверить
+     диапазон символов после декодирования)?
+2.2. Подтверди, что для нашего реального случая (Info-ZIP UTF-8 без флага 0x800) этот порядок даёт
+     корректное имя, а для CP866 1С — не ломает.
+
+## Вопрос 3. ProcessPoolExecutor по страницам / по файлам
+Ты предложил распараллелить извлечение текста. Вопросы:
+3.1. Риск памяти: в контейнере сессия уже держит файлы в памяти (до 500 МБ в session.py). При fork
+     воркеры получают COW-копию памяти родителя. Оцени реальный риск OOM в managed-поде (лимит CPU 2,
+     Memory 4Gi) при 4-8 процессах. Не будет ли хуже, чем текущее последовательное?
+3.2. pdfplumber сам по себе уже использует один процесс. Дай конкретный план безопасного
+     распараллеливания: какие данные передавать в воркер (только bytes страницы или весь файл?),
+     как собирать результаты в порядке индексов, как не раздуть память.
+3.3. Учитывая CPU 2 (2 ядра) — какой реальный выигрыш даст ProcessPool на 2 ядрах? Стоит ли это
+     сложности, или сначала дёшево (П.1 + П.2)?
+
+## Вопрос 4. Что реально тормозит в Spartan10Manual.pdf (70–470с на 14.8 МБ)
+Ты утверждаешь: виноват пустой extract_tables() на скане. Но время скачет 70→470с — это подозрительно.
+4.1. Как точно измерить, что дороже на ЭТОМ файле: extract_text() по страницам или extract_tables()?
+     Дай конкретный способ замера (тайминги по функциям, по страницам), чтобы не гадать.
+4.2. Объясни разброс 70–470с: что в коде/данных может давать такой разброс между запусками
+     (кэши, LLM, сеть к liberta, нагрузка CPU пода)?
+4.3. Есть ли в extract_text() внутри pdfplumber скрытый повторный парсинг (например, повторное чтение
+     объекта при каждом вызове), который можно убрать без смены библиотеки?
+
+## Формат ответа
+- По каждому вопросу: короткий ответ + «факт»/«допущение» + что проверить, если допущение.
+- Без воды, без лирики.