docs(backlog): направления по структуре транскрипта из внешнего ревью

- Зачем:
  - внешнее сравнение с облачным Hypescribe показало: главный разрыв локальной транскрипции — не качество распознавания, а структура (спикеры 2/10 против 8/10); без диаризации MoM не собрать.
- Что:
  - новый раздел «Структура транскрипта»: диаризация как опциональный пост-процессинг (sherpa-onnx vs pyannote, нужен ADR), ручка нарезки абзацев в formatter, словарь замен терминов как запасной план после бенчмарка RNN-T.
  - зафиксировано вне ядра CLI: LLM-чистка и сопоставление имён спикеров.
- Проверка:
  - docs-only, тесты не затронуты.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docs/backlog.md

@@ -82,6 +82,77 @@
 
 ---
 
+## Структура транскрипта (конспекты и MoM)
+
+Источник раздела: внешнее сравнение локального транскрипта (medium,
+openvino-cpu, запись 25:59) с облачным сервисом Hypescribe, критерий —
+пригодность как сырья для конспекта и протокола встречи (GPT-ревью,
+2026-07-10). Итог: по смыслу локальная модель почти равна облаку
+(6.5/10 против 7/10), главный разрыв — **не качество распознавания,
+а структура**: разделение говорящих (2/10 против 8/10) и нарезка на
+реплики. Приоритеты ревьюера: 1) смысл, 2) спикеры, 3) техтермины,
+4) разбивка на фразы, 5) таймкоды. Вывод: локальная диаризация +
+словарь терминов закрывают потребность в облачном сервисе для
+внутренних встреч.
+
+Сознательно вне ядра CLI (максимум — рецепт в README): второй проход
+LLM для чистки текста, сопоставление Speaker N с именами — это работа
+поверх готового транскрипта.
+
+### Диаризация — разделение говорящих
+
+**Что:** Опциональный пост-процессинг (не четвёртый бэкенд): сегменты
+уже несут таймкоды; диаризация даёт интервалы «кто когда говорил»;
+merge по перекрытию интервалов; formatter ломает абзац на смене спикера
+и подписывает `Speaker 1:`. Ставится как extra:
+`uv sync --extra diarization`.
+
+**Почему:** Без спикеров MoM не собрать — это ключевой разрыв с облаком
+по внешнему ревью, и никакое качество распознавания его не компенсирует.
+Заодно естественно решает «разбивку на реплики» (приоритет №4).
+
+**Варианты реализации (ключевое решение, нужен ADR):**
+
+- **sherpa-onnx** — диаризация целиком на onnxruntime (сегментация
+  pyannote в ONNX + спикер-эмбеддинги), без torch, в духе нашего
+  onnx-стека и «no cloud, no API keys».
+- **pyannote.audio** — стандарт качества, но тянет torch и требует
+  HF-токен с принятием лицензии моделей — трение с духом проекта.
+
+**Уточнить перед запуском:** качество обоих вариантов на русской речи
+и перекрывающихся репликах; скорость на CPU (диаризация — второй проход
+по всему аудио); лицензии моделей сегментации/эмбеддингов.
+
+---
+
+### Ручка нарезки абзацев в formatter
+
+**Что:** «Минутные простыни» в транскрипте — не свойство модели, а наши
+константы группировки `_PAUSE_THRESHOLD_S = 2.0` / `_MAX_PARAGRAPH_S =
+60.0` в `formatter.py` (сырых сегментов много: 23-минутная запись — 360
+сегментов, ~4 с на реплику). Вынести в опцию/конфиг или уменьшить
+дефолт.
+
+**Почему откладывается:** при диаризации абзацы будут ломаться по смене
+спикера естественно — сначала решить с диаризацией, чтобы не делать
+ручку, которая устареет.
+
+---
+
+### Словарь замен технических терминов — запасной план
+
+**Что:** Пост-обработка текста сегментов словарём замен по границам слов
+(`CSW → CSV`, `софтп → SFTP`, `ямлик → YAML`, `Spark и Scale → Spark
+SQL`), словарь пользовательский в `.transcriber.toml`.
+
+**Почему запасной:** это тот же класс ошибок, что «кириллизация латиницы
+и искажение имён» из [ADR-006](adr/006-onnx-asr-backend.md), и первым
+его должен попробовать закрыть контекстный декодер GigaAM v3 RNN-T
+(первый пункт бэклога). Заводить словарь — только если бенчмарк RNN-T
+термины не вытянет.
+
+---
+
 ## Авто-детект и UX
 
 ### Включение `onnx` в `--device auto`