docs(execution): описаны владение выполнением и диагностика

ADR-002 и ADR-003 отражают Transcriber как единственного владельца
загрузки и fallback; README получил раздел «Диагностика исполнения»
и уточнение --threads для ONNX; AGENTS.md — новые тестовые паттерны.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/adr/002-batch-and-config.md

@@ -2,6 +2,7 @@
 
 **Статус**: Принято
 **Дата**: 2026-03-18
+**Обновлено**: 2026-09-21 — решения 2 и 4 пересмотрены (см. пометки)
 
 ## Контекст
 
@@ -17,19 +18,23 @@
 
 **Почему**: загрузка модели (large-v3) занимает ~10 секунд и ~3 GB RAM/VRAM. Повторный запуск по уже обработанным файлам должен быть дешёвым no-op.
 
-### 2. TranscribeFileResult: возврат обновлённого состояния модели
+### 2. Состояние модели между файлами
 
-При mid-stream CUDA fallback `_transcribe_file()` перезагружает модель на CPU внутри себя. Чтобы следующие файлы в батче не грузили модель повторно, результат включает обновлённые `model` и `actual_device`.
+**Пересмотрено 2026-09-21.** Исходное решение: `_transcribe_file()` возвращал
+`TranscribeFileResult` с обновлёнными `model`, `backend`, `model_path`
+и `actual_device`, а CLI переносил их в следующий файл после mid-stream
+fallback. Это делало caller владельцем согласованности четырёх полей.
 
-```python
-@dataclass
-class TranscribeFileResult:
-    result: TranscribeResult
-    model: WhisperModel      # может измениться при fallback
-    actual_device: str        # может измениться при fallback
-```
+Теперь состояние не покидает module выполнения: `Transcriber` создаётся один
+раз на запуск после prescan, загружает модель при первом файле и сам держит
+загруженную модель, adapter и фактическое исполнение. Fallback меняет
+состояние внутри module, и следующий файл батча идёт уже по нему. Caller
+получает `TranscribeResult` и `ExecutionInfo` (запрошенное и выбранное
+исполнение, движок, модель, квантизация, потоки, версии runtime).
 
-**Альтернатива**: передавать модель по ссылке через mutable контейнер — менее явно и сложнее тестировать.
+**Альтернатива**: mutable-контейнер с моделью, передаваемый по ссылке, —
+отклонена тогда же; owner-объект решает ту же задачу явно и тестируется
+через свой interface.
 
 ### 3. Конфиг: CWD → глобальный, без мержа
 
@@ -43,15 +48,18 @@ class TranscribeFileResult:
 
 **Приоритет значений**: CLI > конфиг > хардкод.
 
-### 4. `_transcribe_file()` — внутренний helper
+### 4. Публичный `transcribe()` — путь одного файла
 
-Публичный API (`transcribe()`) сохранён без изменений. Новая функция `_transcribe_file()` — внутренний helper с префиксом `_`, не часть публичного контракта.
-
-`transcribe()` стала тонкой обёрткой: `load_model()` + `_transcribe_file()` → `TranscribeResult`.
+**Пересмотрено 2026-09-21.** Внутренние helpers `load_model()`
+и `_transcribe_file()` удалены. `transcribe()` сохранён и стал обёрткой над
+тем же `Transcriber`: `model_name` и `compute_type` без значения берут
+умолчания выбранного исполнения, `device="auto"` означает ONNX CPU, как в CLI.
 
 ## Последствия
 
 - Обратная совместимость CLI: `transcribe file.mp4` работает как раньше
-- Все существующие тесты проходят без изменений сигнатур
-- Batch mode: модель загружается один раз для всех файлов
+- Batch mode: модель загружается один раз для всех файлов; CLI не переносит
+  состояние между файлами
+- Fallback из CLI недостижим: явный device — strict, `auto` — ONNX CPU без
+  переходов. Механизм сохранён для `transcribe(..., strict_device=False)`
 - `--force` флаг для перезаписи существующих транскриптов в батч-режиме